Проектирование базы данных

структура оТчЕта по курсовому проекту

 

1. Описание предметной области

2. Проектирование базы данных

2.1. Объекты предметной области

2.2. Построение ER – модели

2.3. Реляционная модель

3. Проектирование информационной  системы

3.1. Функции информационной системы

3.2. Архитектура информационной  системы

4. Реализация информационной системы

4.1. Средства реализации

Литература

 

Разработка приложения конкретной задачи

1. Описание предметной области

6. РОДДОМ 
Объекты: младенцы, матери, врачи, медсестры (акушерки). 
Условия: Если у матери родились близнецы, то каждый младенец учитывается отдельно. 
Задачи: Проверить, есть ли за заданный период среди родившихся детей близнецы, первый раз мать находится в этом роддоме или нет. Сколько родов принял тот или ной врач, медсестра. Кто принимал роды у данных матери и ребенка. Роды были с осложнениями или без. Сколько времени в роддоме провели мать (до и после родов), ребенок.

- Мать: IDМ, ФИО,  дата рождения, адрес, телефон,  палата, дата поступления. 
- Младенец: IDР, пол, дата рождения, вес, рост. 
- Врач: IDВ, ФИО, дата рождения, дата приема на работу, квалификация, зарплата. 
- Медсестра: IDА, ФИО, дата рождения, дата приема на работу, квалификация, зарплата.

 

Определим задачу, связанную с деятельностью родильного дома. Для анализа работы необходимо иметь информацию обо всех родах, прошедших в отделении. Для этого нужно хранить данные о пациентах (матерях и детях) и мед.персонале (врачах и медсестрах).

Роддом принимает  рожениц как непосредственно  перед родами, так и за 2–3 месяца до родов — на сохранение. На каждую роженицу заводится учетная карточка, которая сохраняется в течение длительного времени. В карточку заносятся сведения обо всех пребываниях роженицы в стационаре.

Во время пребывания в стационаре за каждой роженицей  закрепляется врач, наблюдающий ее до момента выписки, и медсестры.

Процесс родов  подлежит специальному учету: регистрируется начало и окончание родов, фиксируется ход родов. После родов каждый ребенок получает специальную бирку, по которой он будет идентифицироваться в первые дни своей жизни. В регистрационной книге сохраняется информация о точном времени рождения ребенка, его имени, росте и весе.

2. Проектирование базы данных

Как известно, целью  проектирования базы данных (БД) является получение эффективной БД. Структура БД должна быть гибкой и адаптивной, алгоритмы обработки должны быть эффективными.

Структура БД зависит  от того, что мы собираемся делать с  данными, характеризующими предметную область.

Процесс разработки структуры  базы данных в соответствии с требованиями пользователей называется проектированием базы данных. Поэтому перед проектировщиком базы данных (администратором базы данных) возникают следующие вопросы:

1) что представляют собой  требования пользователей и в  какой форме они могут быть  выражены;  

2) как эти требования  могут быть преобразованы в  эффективную структуру базы данных;

3) как часто и каким  образом структура базы данных  должна перестраиваться в соответствии с новыми или изменяющимися требованиями?

При проектировании базы данных можно пользоваться широко известными методами проектирования программного обеспечения, а именно, методом нисходящего проектирования с последовательными итерациями.

Информационные требования пользователей удобно разделять  на информацию, формирующую концептуальное структурное представление, и информацию, формирующую концептуальное прикладное представление.

Информация, отнесенная к  концептуальному структурному представлению (ISP - information structure perspective), описывает естественные концептуальные связи всех данных в базе данных. Она не связана ни с конкретным способом обработки, ни с конкретным приложением. ISP-информация отображает образы реального мира в сущности и атрибуты (свойства сущности), а взаимосвязи между образами реального мира – в связи между элементами данных.

Информация, отнесенная к  концептуальному прикладному представлению (UP - usage perspective), определяет требования организации к обработке данных. Эта информация описывает (в отличие от естественных концептуальных связей и данных) данные и связи, используемые в приложениях.

Между этими двумя  представлениями существует значительное пересечение. Используемые в приложениях элементы данных, входящие в состав UP-информации, представляют собой соответствующее подмножество элементов данных, содержащихся в ISP-информации, при условии, что набор ISP-информации является полным и согласованным.

Каждый из этих наборов требований воздействует на результаты проектирования в разных направлениях: ISP обеспечивает гибкость и адаптивность, а UP - эффективность.

 

1. Объекты предметной области

Определим объект как «нечто, о чем мы хотим хранить  информацию».

Тогда для нашей  задачи можно определить объекты Младенец, Мать, Врач, Медсестра, Роды. Между объектами существуют связи или отношения, объединяющие их друг с другом. Связи между объектами могут рассматриваться как объекты. Объект Роды связывает объекты Младенец, Мать, Врач и Медсестра.

Обоснование выделения  родов как объекта состоит в следующем.

Если нужно  иметь полный список врачей, медсестер, детей или консультантов, то его можно получить из объекта Консультант. Если же такого объекта нет, то получить список консультантов можно из объекта Заказ. Но, во-первых, это не так просто, как из объекта Консультант, а во-вторых, может быть, не все консультанты есть в объекте Заказ.

То же самое  относится к клиентам. Если объекта Клиент нет, то получить список клиентов можно только из объекта Заказ.

 

2. Построение ER-модели

Структуру базы данных (БД) представим, используя терминологию модели высокого уровня – ER–модели (Entity – Relationship сущность – связь). ER–модель – это средство представления схемы предметной области, не зависящей от СУБД.

Базовыми структурами  в ER-модели являются типы сущностей  и типы связей. Структура базы данных, соответствующая ER-модели, может быть изображена в форме ER-диаграммы (ERD).

Множество сущностей  представляется в ERD помеченным прямоугольником. Множества связей изображается в ERD помеченным ромбом. Множества сущностей, которые участвуют во множестве связей, присоединяются к последнему дугами. В ER-модели связи могут быть N-арными, взаимно однозначными, функциональными или относящиеся к типу "многие-ко-многим".

Простота, применение естественного языка  и легкость понимания позволяют использовать эту модель как инструмент для общения с будущими пользователями, для сбора информации о предметной области, для проектирования базы данных.

На рис. 1.1 показана ERD – диаграмма ER–модели ПО.

ER – модель  позволяет определить структуру  БД в терминах объектов задачи: Клиент, Консультант, Товар, Заказ.

В терминологии ER – модели Клиент, Консультант, Товар, Заказ являются сущностями (E – entity). Сущность представляет собой основное содержание явления или процесса, о котором необходимо собрать и хранить информацию.

 

 

 

 

 

 

 

 

 

Рис. 1.1 ERD – диаграмма модели ПО

 

3. Реляционная модель

Модель данных определяет правила, в соответствии с которыми структурируются данные. Структуризация данных определяется разнообразием и количеством типов объектов модели данных, ограничениями на структуру данных.

Реляционная модель данных базируется на отношениях и их представлении в виде таблиц. Единственным средством структуризации данных в реляционной модели является отношение (Relation). Отношения обладают всеми свойствами множеств. Важнейшим свойством языков данных реляционной модели является возможность определять новые отношения, основываясь на существующих отношениях.

В терминологии реляционной модели объекты предметной области представляются отношениями (таблицами). Объекты Клиент, Консультант, Товар, Заказ характеризуют предметную область, то есть имеют отношение к предметной области. Отношение Заказ связывает отношения Товар и Консультант. Связь означает, что «много» Консультантов заказывают один и тот же товар и «много» товаров заказываются одним и тем же консультантом.

Отношение Консультант связано с отношением Клиент. Связь означает, что у одного и того же консультанта может быть несколько клиентов, число которых может увеличиваться.

Отношение отображается таблицей, каждая строка которой представляет кортеж. Столбцы таблицы называют атрибутами. Количество столбцов таблицы равно степени отношения, а число строк (кортежей) – его мощности.

Единственными отношениями, допустимыми в реляционной модели, являются те, которые удовлетворяют  следующему условию: «Каждое значение в отношении, то есть значение каждого атрибута в каждом кортеже, является атомарным (неделимым)». Отношение, удовлетворяющее этому условию, называется нормализованным.

Из того факта, что отношение есть множество, следует, что никакие два кортежа не совпадают и что упорядоченность  кортежей несущественна. Это ограничение  приводит к понятию ключа отношения.

Ключ отношения – это атрибут или набор атрибутов, однозначно идентифицирующих кортеж в отношении.

Таблица (отношение) может иметь и несколько ключей, называемых  
возможными ключами. Для того чтобы исключить тривиальные ключи, потребуем, чтобы ключ обладал следующими двумя свойствами: однозначностью идентификации и неизбыточностью (никакое подмножество атрибутов ключа не обладает свойством однозначности идентификации).

Один из возможных  ключей выбирается в качестве первичного ключа отношения. Ни одно из значений первичного ключа не может быть нулевым.

В отношении Клиент в качестве ключа можно использовать атрибут «ФИО» – это естественный ключ, так как связан непосредственно с семантикой предметной области.

Но можно в  качестве ключа использовать номер  строки (идентификатор строки) – тогда такой ключ называется искусственным ключом.

Для отношения Клиент введем искусственный ключ «номер клиента», для отношения Консультант – искусственный ключ «номер консультанта». Тогда отношение Заказ в качестве первичного ключа будет иметь набор атрибутов: «номер клиента», «номер консультанта», то есть составной ключ.

Введение ключа  приводит к уменьшению избыточности данных в отношении Заказ.

Аналогично для  отношения Товар введем искусственный ключ «номер товара». Тогда в отношении Заказ вместо названия заказанного товара будем использовать «номер товара», что приводит к уменьшению избыточности данных в отношении Заказ. Если бы отношения Товар не было, то его следовало бы создать с целью уменьшения избыточности данных в отношении Заказ.

Е.Кодд первоначально  определил три уровня нормализации, которые он назвал первой, второй и  третьей нормальными формами. Нормализованное отношение всегда находится в первой нормальной форме (1НФ).

Отношение, даже если оно находится в 1НФ, может  все же обладать некоторыми нежелательными свойствами.

Отношения Клиент, Консультант и Товар находятся во 2НФ, так как эти отношения находятся в 1НФ и атрибут «ФИО клиента» функционально полно зависит от первичного ключа «номер клиента», атрибут «название товара» функционально полно зависит от первичного ключа «номер товара» и атрибут «название Консультанта» функционально полно зависит от первичного ключа «номер консультанта».

Отношения Клиент, Консультант и Товар находятся в 3НФ, так как они находятся во 2НФ и неключевой атрибут в каждом отношении нетранзитивно зависит от первичного ключа.

Отношение Заказ  находится во 2НФ, так как оно находится в 1НФ и атрибут «количество товара» функционально полно зависит от первичного ключа «номер консультанта», «номер клиента» (составного ключа). Отношение Заказ находится в 3НФ, так как атрибут «сумма» нетранзитивно зависит от первичного ключа.

Уровень нормализации отношения определяется семантикой данных. Перед тем, как сделать  заключение, находится ли отношение  в 3НФ, необходимо знать содержание данных, то есть имеющиеся зависимости между данными. Выявление функциональных зависимостей является существенной частью понимания семантики данных.

 

3. Проектирование информационной системы

База данных –  это совокупность отношений (таблиц), характеризующих предметную область. Схему базы данных можно рассматривать как совокупность типов данных, определяемых отношениями. Ограничения, определенные в схеме, могут использоваться для контроля данных того или иного типа.

Схема отношения (таблицы) задается именем таблицы и  именем соответствующих атрибутов. Каждому отношению и его атрибутам (свойствам) поставим в соответствие имена латинскими буквами.

Таблица 1.1 Отношение Консультант – таблица Consul

Атрибут	Комментарий
n_consul	Номер консультанта – ключевой атрибут
fio	ФИО консультанта

 

Таблица 1.2 Отношение Клиент – таблица Client

Атрибут	Комментарий
n_cl	Номер клиента – ключевой атрибут
fio_cl	ФИО клиента
n_consul	Номер консультанта

 

Таблица 1.3. Отношение Заказ – таблица Zakaz

Атрибут	Комментарий
nomer	Номер заказа
n_consul	Номер консультанта – сост. ключ
n_client	Номер клиента – сост. Ключ
n_tov	Номер товара
kolvo	Количество
date	Дата заказа

 

Таблица 1.4 Отношение Товар – таблица Tovar

Атрибут	Комментарий
n_tov	Номер товара – ключевой атрибут
nazv	Наименование товара
d_vip	Дата выпуска
d_god	Срок годности
srok	Срок использования
pr_opt	Оптовая цена
pr_rozn	Розничная цена
sklad	Количество на складе

Реляционная схема  БД с выделенными ключевыми атрибутами может быть представлена в следующем  виде:

Consul (n_consul, fio)

Client (n_cl, fio_cl, n_consul)

Zakaz (nomer, n_consul, n_client, n_tov, kolvo, date)

Tovar (n_tov, nazv, d_vip, d_god, srok, pr_opt, pr_rozn, sklad)

Введем понятие  домена. Домен – это множество значений, из которого извлекаются фактические значения, появляющиеся в данном столбце. Следует отметить, что значения атрибутов, являющихся ключами отношений, извлекаются из множества натуральных чисел. Значения атрибутов fio, fio_cl и т.д. – из множества символьных данных, значения атрибута date извлекаются из множества дат.

1. Функции информационной системы

Главными функциями  информационной системы (ИС), то есть приложения, являются просмотр и редактирование данных о клиентах и консультантах – основных объектах задачи. Кроме того, важной функцией является редактирование данных о товарах, то есть добавление и (или) изменение товаров на склад, составления заказов.

Для объекта Клиент вводятся операции:

• показать список всех клиентов;
• показать список клиентов определенного консультанта;
• добавить нового клиента;

 Для объекта Консультант вводятся операции:

• показать список всех консультантов;
• добавить нового консультанта;

Для объекта Товар вводятся операции:

• показать список всех товаров;
• добавить новый товар;

Для объекта Заказ вводятся операции:

• показать список всех заказов;
• создать новый заказ;

Операция, связанная  с удалением данных в объектах, не является типичной для выбранной предметной области.

Для имеющихся  данных могут быть сформулированы следующие  операции (запросы):

• показать товары на складе;
• показать товары у консультантов;
• показать денежный баланс консультанта;
• показать список постоянных клиентов консультанта;
• показать самого успешного консультанта;
• показать самый ходовой товар

При необходимости  список запросов может быть дополнен, несмотря на небольшое количество объектов задачи. Дело в том, что заказчик (пользователь) ИС всегда хочет больше, чем реализовано. Поэтому ИС должна быть гибкой, то есть способной к изменению и добавлению (расширению) в минимальные сроки с максимальной отдачей.

2. Архитектура информационной системы

Архитектура ИС задачи представлена на рис. 1.3.

 

 

 

 

 

 

 

 

 

Рис. 1.3 Архитектура ИС

 

4. Реализация информационной системы
1. Средства реализации

СУБД Visual FoxPro (VFP) для реализации информационной системы (ИС) имеет следующие средства:

– базовые возможности полнофункциональной интегрированной среды программирования Visual FoxPro с использованием объектно-ориентированного программирования;

– визуальные средства, которыми можно воспользоваться из главного меню СУБД Visual FoxPro;

– язык программирования СУБД Visual FOXPRO с полным набором операторов (команд);

– специализированный язык запросов – SQL (Structured Query Language).

 

Основные объекты СУБД Visual FoxPro

В СУБД Visual FoxPro можно выделить следующие основные объекты:

 проект, база данных, таблицы и индексы, хранимые процедуры и триггеры, относящиеся непосредственно к базе данных;

 представления данных (просмотры), запросы, отчеты, формы, программы, меню, классы.

Проект (объект Project) используется для объединения элементов приложения. Проект играет роль каталога, содержащего элементы приложения (информационной системы конкретной задачи – конкретной предметной области), упрощая разработку приложения.

База данных (объект Database) состоит из таблиц, индексов, триггеров и хранимых процедур. Каждая таблица имеет имя и хранится в отдельном файле с расширением DBF (data base file – файл базы данных). Каждая таблица может иметь несколько индексов, используемых для упорядочения данных и быстрого поиска данных. Индексы хранятся в файле с тем же именем, что и таблица, но с расширением CDX – составной индексный файл (мультииндексный файл), хранящий сразу несколько индексных выражений.

Хранимые процедуры и триггеры позволяют обрабатывать события, возникающие при редактировании данных. Эти объекты являются частью базы данных и определяются при описании таблиц с целью проверки вводимых данных.

Представления данных (Views) позволяют объединять данные таблиц и представлять их в более удобном виде. Представления – это виртуальные таблицы. Они похожи на обычные таблицы, но не являются физическими объектами хранения данных. Представления существуют в базе данных до тех пор, пока не будут принудительно удалены. Количество представлений в базе данных обычно превосходит количество таблиц. Во многих информационных системах (приложениях) доступ к данным осуществляется только с помощью представления данных. Представления используются для выборки данных в формах, отчетах, при создании запросов и в программах.

Формы, отчеты, запросы и программы используются для отображения и редактирования данных.

Формы (объект Form) используются для просмотра и ввода данных в таблицы, отображения их на экране или управления работой приложения (ИС). Данные можно вводить в таблицы и непосредственно, без применения форм. Для создания формы используются мастер форм и конструктор форм. Мастер форм предоставляет ряд шаблонов, которыми можно воспользоваться. Конструктор форм предназначен для создания сложных форм.

Формы как объекты  предоставляют разработчику множество  свойств, событий и методов, которые позволяют управлять внешним видом окна и на созданном окне размещать различные элементы управления. Объект Form является контейнером, в который помещаются другие объекты. Это позволяет расширить собственную функциональность, а также позволяет организовать интерактивный диалог с пользователем.

Отчет (объект Report) – это форматированное представление данных, выводимое на экран, в файл или на печать. Поддерживается вывод отчетов в разных форматах, в число которых входят XML, HTML. Для создания отчетов, как и для форм, используются мастер форм и конструктор форм.

Запросы являются средством выборки данных из одной или нескольких таблиц. Для реализации запроса используются следующие средства: специализированный язык запросов – SQL (Structured Query Language), конструктор запросов и программа на алгоритмическом языке Visual FoxPro. Результаты выполнения запроса могут выводиться в виде отчета, отображаться в форме или сохраняться в указанной таблице.

Программы, написанные на алгоритмическом языке Visual FoxPro, являются объектно-ориентированными. С помощью программ обрабатываются события в форме, создаются объекты, осуществляются вычисления, происходит управление базой данных. Можно объединять программы в библиотеки. Для создания форм используются как базовые классы, так и собственные пользовательские классы. Классы, созданные в VFP, хранятся в библиотеках классов.

Меню является основной формой диалога в информационных системах обработки данных. Для создания меню используется генератор (конструктор) меню. Генератор меню создает программу, которая запускается на выполнение. Полученную программу можно просматривать и редактировать.

Для создания объектов и работы с  ними в Visual FoxPro существуют специальные средства – конструкторы (Designers) и мастера (Wizards). Они предоставляют удобные возможности, позволяющие создавать нужные объекты информационных систем (приложений).

Основные  конструкторы (Designers)

Конструктор Базы Данных (Database Designer)

Конструктор базы данных предоставляет средства для создания объекта БД (Database). С его помощью можно создавать, добавлять, удалять таблицы, связывать их так называемыми «постоянными связями» (которые очень наглядно отображаются), определять правила ссылочной целостности, создавать хранимые процедуры, триггеры.

Конструктор таблиц (Table Designer)

Конструктор таблиц предназначен для создания таблиц и определения их структуры, создания индексов, определения правил ввода как для полей, так и для записей в целом. Кроме того, с помощью конструктора определяются триггеры для событий удаления, модификации и вставки записи.

Конструктор запросов (Query Designer)

Конструктор запросов позволяет визуальными средствами создавать запросы к БД на языке SQL.

Конструктор представлений (View Designer)

Конструктор предназначен для создания представлений – SQL-запросов, хранящихся в БД. Представления позволяют редактировать данные.

   Конструктор форм (Form Designer)

Конструктор форм предоставляет удобные средства для создания пользовательского интерфейса.

Конструктор отчетов (Report Designer)

Этот конструктор  предназначен для создания отчетов  – средств вывода на печать содержимого  таблиц, результатов запроса.

Кроме того, существуют так называемые мастера (Wizards) – средства для автоматизации создания данных объектов. Они предоставляют разработчику ряд вопросов и после ответа на них автоматически создают готовые объекты. Мастера не имеют всех возможностей конструкторов.

Управление  проектом

Основой любого приложения в VFP является проект (Project). Проект – средство объединения элементов приложения в единое целое. Проект играет роль каталога, который содержит все, что касается реализации данной задачи. Для управления проектом существует Менеджер Проектов (Project Manager).

Проект объединяет следующий универсальный набор типов элементов, необходимый для создания приложения любой предметной области:

• Data (Данные) – БД, таблицы, представления, запросы.
• Documents (Документы) – формы, отчеты.
• Classes (Классы).
• Code (Код) – программы.
• Other (Остальное) – меню, файлы переменных, макрокоманды.

Менеджер Проектов выполнен в виде многостраничного блокнота, на каждой странице которого представлены указанные  элементы.

Менеджер Проектов является центром  управления всеми элементами, входящими  в приложение.

Каждый элемент может быть представлен  в одном из двух состояний: закрытом (признак «+») или открытом (признак  «–»).

Файлы в проекте  классифицируются по видам. Каждый элемент  проекта отображает свои файлы.

Элемент All отображает все файлы.

Элемент Data (данные) отображает базу данных (файлы с расширением DBC, DCT, DCX), таблицы, представления, запросы (файлы с расширением DBF, FPT,CDX), хранимые процедуры.

Элемент Documents (документы) – формы (файлы с расширением SCX, SCT) , отчеты (файлы с расширением FRT, FRX) .

Элемент Classes (классы) – файлы библиотек классов. Если раскрыть библиотеку, то будет показан список входящих в нее классов.

Элемент Code (код) – программы (файлы с расширением PRG, FXP) .

Элемент Other (остальное) – меню (файлы с расширением MNT, MNX, MPR, MPX), файлы переменных, макрокоманды.

ЛИТЕРАТУРА

1. Карпова Т.С. Базы данных: модели, разработка, реализация. – СПб.: ПИТЕР, 2002.
2. Клепнин В.Б., Агафонова Т.П.Visual FoxPro 9.0. – СПб: БХВ-Петербург, 2007.
3. Попов А.А. Программирование в среде СУБД FoxPro 2.0. Построение систем обработки данных. – М.: Радио и связь, 1993.
4. Амелина Н.И., Мачулина Л.А. Методические указания по курсовому проектированию по курсу «Базы данных» для студентов механико-математического факультета вечернего и дневного отделения. – Ростов-на-Дону, УПЛ РГУ, 1999.
5. Невская Е.С., Амелина Н.И., Мачулина Л.А. Введение в системы баз данных Методические указания для студентов вечернего и дневного отделения механико-математического факультета. – Ростов-на-Дону, УПЛ РГУ, 2003.
6. Невская Е.С. Базы данных. Часть 1. Методические указания для 
   студентов 3 и 4 курсов механико-математического факультета. – Ростов-на-Дону, УПЛ РГУ, 1996.
7. Невская Е.С. Базы данных. Часть 2. Методические указания для  
   студентов 3 и 4 курсов механико-математического факультета. – Ростов-на-Дону, УПЛ РГУ, 1997.