
- •Дипломный проект
- •1. Введение
- •Эскизный проект Литературный обзор.
- •2.1. Базы данных, отношения и реляционные базы данных
- •2.1.1. Базовые концепции
- •2.1.2. Определение отношения
- •2.1.3 Определение реляционной бд
- •3. Постановка задачи
- •Требования, предъявляемые к системе автоматизированного учета.
- •Выбор платформы проектирования, обоснование
- •4. Технический проект
- •Общая структура системы
- •Структуры данных
- •4.3. Связи между объектами
- •4.4. Лингвистическое описание
- •Алгоритмические связи
- •4.6. Информационные потребности пользователя
- •Ограничение целостности
- •4.8. Даталогическая модель данных
- •Технический проект
- •Заключение
Эскизный проект Литературный обзор.
Для облегчения понимания поставленной задачи и методов её решения, был сделан литературный обзор по важнейшим понятиям, использованным при разработке и описании данного дипломного проекта.
Данный литературный обзор поясняет общие концепции, определение, содержание и методику разработки баз данных (БД), отношения, описываемые БД, так же подробно рассмотрен пример реляционной БД, аналогичной по структуре той, которая была создана в результате дипломного проектирования
2.1. Базы данных, отношения и реляционные базы данных
2.1.1. Базовые концепции
Базу данных можно определить как унифицированную совокупность данных, совместно используемую всем персоналом предприятия, банка или учебного заведения. Задача БД состоит в хранении всех представляющих для некоторого предприятия интерес данных в одном месте, причем таким способом, который заведомо исключает их избыточность. Хранение множественных копий данных в различных местах предприятия чревато возникновением рассогласований между предположительно идентичными наборами данных. В хорошо спроектированной БД избыточность данных исключается, и вероятность сохранения противоречивых данных минимизируется.
В больших компьютерных системах к данным, хранящимся в БД, доступ может осуществляться одновременно сотней и более пользователей. БД в таких случаях может иметь сотни полей данных с миллионами единиц информации. Такие системы могут содержать буквально все данные, требующиеся для управления предприятием. БД на микрокомпьютерных системах имеют гораздо меньший масштаб. Здесь к конкретной БД в некоторый момент времени обычно осуществляет доступ один пользователь и каждая БД содержит только некоторое подмножество данных, требующихся предприятию. Одна БД разрабатывается, скажем, для хранения финансовой информации, другая - данных о персонале. Будет ли разрабатываемая БД размещаться на большой ЭВМ или на микрокомпьютере - функции СУБД в обоих случаях одинаковы. СУБД представляет собой программно-аппаратный пакет, обеспечивающий пользователям простой доступ к БД. Программная часть СУБД, которую некоторые изготовители называют менеджером БД, выступает в качестве интерфейса между пользователем и БД (рис. 1.1). Менеджер БД обеспечивает программные средства, необходимые для создания, загрузки, запроса и обновления данных. Менеджер также контролирует все действия, связанные с управлением вводом-выводом и памятью БД, а на больших ЭВМ на него возлагается и решение проблем безопасности и совместного использования данных. Короче говоря, хорошо спроектированная СУБД обеспечивает программное обеспечение, упрощающее для пользователя общение с БД.
Рис 1.1 Основные компоненты архитектуры СУБД
Другое сходство между большими и малыми СУБД заключается в том, что в обоих случаях сама БД должна быть хорошо спроектирована, если мы хотим, чтобы система баз данных как единое целое функционировала должным образом. Цель книги состоит в выделении и описании некоторых базовых процедур проектирования для определенного типа БД, а именно реляционных. Предполагается, что пользователь будет устанавливать БД на микрокомпьютерной системе; однако, те же алгоритмы проектирования применимы к БД, проектируемым для больших компьютерных систем.