Проектирование базы данных «Учащиеся»

Попытаемся задать ограничения  на объекты и их характеристики.

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

Типы связей. Все информационные объекты предметной области связаны  между собой.

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

а) один к одному (1:1);

б) один ко многим (1:М);

в) многие ко многим (М:М).

Связь один к одному (1:1) предполагает, что в каждые момент времени одному экземпляру информационного объекта А соответствует не более одного экземпляра информационного объекта В и наоборот.

Рис. 1 иллюстрирует указанный тип отношений:

 
А1 
 
 
 
Рис. 1. Графическое изображение реального отношения 1:1

Примером связи 1:1 может  служить связь между информационными  объектами УЧИТЕЛЬ и КЛАССНЫЙ РУКОВОДИТЕЛЬ

При связи один ко многим (1:М) одному экземпляру информационного объекта А соответствует 0, 1 или более экземпляров объекта В, но каждый экземпляр объекта В связан не более чем с 1 экземпляром объекта А. Графически данное соответствие имеет вид, представленный на рис. 2.

 
 
 
 

 

 

Рис. 2. Графическое изображение реального отношения 1:М

Примером связи 1:М служит связь между информационными  объектами УЧЕНИК и УЧИТЕЛЬ

Связь многие ко многим (М:М) предполагает, что в каждый момент времени одному экземпляру информационного объекта А соответствует 0, 1 или более экземпляров объекта В и наоборот. На рис. 3 графически представлено указанное соответствие.

 
 
 

 

 

Рис. 3. Графическое изображение реального отношения М:М

Примером связи М:М  служит связь между информационными  объектами УЧИТЕЛЬ и КАБИНЕТ.

 

3. Построение концептуальной модели предметной области.

 

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

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

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

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

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

1.2.2 Инфологическое проектирование

 

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

Инфологическое проектирование, прежде всего, связано с попыткой представления семантики предметной области в модели БД. Реляционная  модель данных в силу своей простоты и лаконичности не позволяет отобразить семантику, то есть смысл предметной области.

Проблема представления  семантики давно интересовала разработчиков, и в семидесятых годах было предложено несколько моделей данных, названных семантическими моделями. К ним можно отнести семантическую  модель данных, предложенную Хаммером (Hammer) и Мак-Леоном (McLeon) в 1981 году, функциональную модель данных Шипмана (Shipman), также созданную в 1981 году, модель "сущность—связь", предложенную Ченом (Chen) в 1976 году, и ряд других моделей. У всех моделей были свои положительные и отрицательные стороны, но испытание временем выдержала только последняя. И в настоящий момент именно модель Чена "сущность—связь", или "Entity Relationship", стала фактическим стандартом при инфологическом моделировании баз данных.

Модель «сущность-связь» называют также «ER-моделью» (essence-сущность, relation-связь).

 

ER-модели

Для основных элементов — сущностей, связей, атрибутов — в ER-моделях  используются следующие обозначения (надписи на всех рисунках будут  сделаны на этапе верстки):

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

Если на этапе построения ER-модели определяются атрибуты, являющиеся первичными ключами соответствующих сущностей, то они, как правило, подчеркиваются.

Принадлежность атрибутов сущностям  и связи между сущностями обозначают линиями. Линии, обозначающие связи, снабжаются указаниями на тип связи (“один к  одному”, “один ко многим”, “многие  ко многим”). Единого стандарта на способ обозначения типа связи нет, в последнее время одним из наиболее удобных и наглядных  признан стиль, который используется в Microsoft Access. Согласно ему связи обозначаются цифрой 1 на стороне “одного” и символом “Ґ” на стороне “многих”.

Рассмотрим примеры из близкой  всем нам школьной жизни.

Сущность “ученик”

Атрибуты — уникальный (допустим — в пределах данной школы) номер, фамилия, имя, дата рождения.

Сущность “учитель”

Атрибуты — уникальный номер, фамилия, имя, отчество.

Сущность “предмет”

Атрибуты — уникальный номер, название.

Сущность “класс—ученик”

Тип — “один ко многим”.

Сущность “учитель—предмет”

Тип — “многие ко многим”.

Связи, как и сущности, могут  иметь атрибуты. Например, администрацию  школы нередко интересует стаж преподавания данным учителем данного предмета. Если подобную информацию необходимо хранить, то естественно добавить “стаж” в качестве атрибута связи “учитель—предмет”.

Переход от ER-модели к реляционной

Описанию реляционной модели данных посвящена отдельная статья (см. “Реляционные БД” 2).

При переходе от ER-модели к даталогической реляционной модели, как правило:

— каждая сущность описывается отдельной  таблицей;

— атрибуты становятся полями таблиц, для них задаются подходящие типы данных, имеющиеся в используемой СУБД;

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

— для связей “многие ко многим”  вводятся соответствующие таблицы, снабженные, возможно, требуемыми атрибутами;

— при необходимости производится нормализация таблиц до заданной нормальной формы.

 

1.2.3 Реляционная модель БД

 

Реляционная модель баз данных была предложена сотрудником фирмы  IBM Э. Кодом в начале 70-х годов. Будучи математиком, он предложил использовать для обработки данных аппарат теории множеств (объединение, пересечение, разность и Декартово произведение). Он показал, что любое представление данных сводится к совокупности двумерных таблиц особого вида, известных в математике как отношения.

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

Реляционная БД представляет собой информацию об объекте, представленную в виде двумерного массива - таблицы  объеденных определен 
ными связями.

Выбор ключей.

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

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

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

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

Атрибут учащиеся так же имеет уникальные поля, такие как ИНН, серия и номер свидетельства о рождении, номер ученика, свидетельство о рождении не может являться ключом так как, вместо свидетельства о рождении  а ИНН может являться ключевым, но нам удобнее использовать как ключ номер ученика.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

ГЛАВА 2. РЕАЛИЗАЦИЯ БАЗЫ ДАННЫХ «УЧАЩИЕСЯ»

 

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

 

2.1 Анализ и выбор СУБД для разработки базы данных

 

Современная FireBird

Сейчас с уверенностью можно  говорить, что FireBird — развитое промышленное программное обес-печение, гарантирующее  транзакционную целостность данных при использовании его с множеством пользователей, соответствующее правилам ACID:

Atomicity — атомарность транзакций;

Consistency — целостность данных;

Isolation —изолированность  
(контроль доступа пользователей);

Durability — долговременность хранения данных.

Предназначенная для клиент-серверной  архитектуры, эта СУБД предъявляет  достаточно типичные требования при  выборе серверного оборудования для  серьезных проектов. А способность  отлично работать с большими базами и множеством клиентских подключений  давно успешно доказана как на выставках, так и в реальных коммерческих проектах. Тут действует универсальное правило — качество работы базы сильно зависит от того, кто ее проектировал.

В настоящее время можно насчитать  три стабильные современные ветви FireBird — это FB 2.0.x, FB 1.5.x. и вышедший во второй половине апреля 2008 г. релиз FB 2.1.

Уже в версии 1.5 все модули были аккуратно переписаны с учетом современных  стандартов языка C++. Версия 2.1 имеет  футурологическую направленность: в  нее успели заложить некоторые элементы, запланированные для архитектуры 3.0. В этой версии были добавлены  триггеры для общих событий базы данных, глобальные временные таблицы, выражение «UPDATE OR INSERT», использование  доменов для аргументов и переменных процедурного языка.

А вот «рабочей лошадкой» на апрель 2008 г. можно считать версию 2.0.x.

Конечно, применение СУБД FireBird очень  часто сопровождается использованием среды разработки Delphi, но она подойдет и не только для Delphi-разработчиков. Существуют бесплатно распространяемые драйверы для ODBC, Java, .NET (1.1, 2.0, 3.5), а также  библиотеки для низкоуровневого  доступа через C++.

FireBird предоставляет возможности,  стандартные для современных  промышленных СУБД: триггеры, просмотры,  хранимые процедуры, анонимные  блоки, функции, заданные пользователем,  домены, события, исключения, инкрементное резервное копирование данных. И при этом у «жар-птицы» остается отличительная черта — невысокие требования к аппаратным ресурсам и относительно простой процесс установки. Более того, в FireBird есть отдельный вариант сборки для встроенных однопользовательских решений (Embedded FireBird), работающий на одной-единственной библиотеке. Но при этом обеспечивается полная совместимость структуры базы для основного варианта использования этой СУБД.

2.2 Состав таблиц БД

 

Рассмотрим отношения  нашей БД подробнее.

Таблица 1«УЧЕНИКИ»  

Название	Тип данных	Тип поля
ИД_Ученики	Счетчик	Ключевое
Фамилия	Текстовый
Имя	Текстовый
Отчество	Текстовый
Возраст	Числовой
Класс	Текстовый
ФИО родителей	Текстовый
Серия и номер паспорта (свидетельства о рождении)	Текстовый	Уникальное
Какой язык изучает	Текстовый
Участие в олимпиадах, различных  конкурсах	Текстовый