Анализ       Справочники       Сценарии       Рефераты       Курсовые работы       Авторефераты       Программы       Методички       Документы     опубликовать

Бд и субд. Классификация и примеры




Скачать 326.53 Kb.
НазваниеБд и субд. Классификация и примеры
страница1/3
Дата01.10.2014
Размер326.53 Kb.
ТипДокументы
  1   2   3

БД и СУБД. Классификация и примеры

БД – совокупность данных, содержащая информацию о конкретной предметной области. БД должна удовлетворять следующим требованиям: согласованность (все объекты предметной области должны быть взаимосвязаны между собой и логически непротиворечивы), самодокументированность (в реляционных БД должны храниться не только таблицы с данными, но и структура этих таблиц и другая вспомогательная информация, образующая методанные), многопользовательский режим доступа, независимость от программного обеспечения. БД хранятся в файлах, но эти свойства отличают их от обычных файлов, которые используются в большинстве прикладных программ. СУБД – программный комплекс для управления БД. Архитектуры систем БД. 3 основных: 1. плоские (персональные) БД. БД находится на том же компьютере, что и СУБД. Подходит для личных справочных систем. Примеры: MS Access, Paradox, Dbase, FoxPro. Все эти СУБД могут работать в сети. 2. файл-серверная архитектура. Картинка. Основной недостаток системы – перегрузка сети. Файлы качаются в полном объеме. Трудность многопользовательского режима. 3. клиент-серверная архитектура. Картинка. Формулирует запрос на стандартном языке SQL. Выполнением занимается сервер, все централизовано. Результат отсылается клиенту: та часть, которая ему нужна. Серверы БД: 1. Oracle, 2. MS SQL Server 2000,2005,2008, Express Edition – бесплатный, 3. My SQL совершенно бесплатный, 4. Fire Bird – бесплатный сервер (InterBase). Функции серверов БД: 1. Выполнение запросов; 2. Поддержка согласованного целостного состояния. Сервер в обязательном порядке следит за соблюдением бизнес-правил – требований к состоянию базы. Выполнение задач происходит с помощью транзакций – группа операций, рассматриваемых как единое целое. 3. Организация многопользовательской работы – предотвращение и разрешение коллизий. 4. Поддержка безопасности. Безопасность обеспечивается наличием разрешений как на отдельные таблицы, так и на столбцы, на различные операции (чтение, запись), наличием категорий пользователей, парольной защитой, т.е. аутентефикацией пользователей.
Модели данных, пример реляционной модели

3 уровня моделей: 1. внешние модели, 2. концептуальный модели, 3. физические (внутренние) модели. 1. Внешние модели описываются в виде экранных форм, отчетов и т.д. 2. Концептуальная модель – это обобщенная модель предметной области, отражающая логические связи между данными. Бывают: инфологическая (семантическая) смысловая модель, фактографическая. Инфологическая модель – сущьность-связь, E-R модель Entity-Relationship. В графической форме отражается структура объектов предметной области и связи между ними. Фактографические модели описывают способы сбора и представления фактов. 90% и более СУБД используют реляционную модель. Ранее использовались иерархическая модель и сетевая модель, но это уже история. Иногда встречаются объектно-ориентированные и объектно-реляционные модели. Концептуальная модель используется проектировщиком БД. 3. Физическая модель – это внутренний формат данных, способ их хранения на диске. У каждой СУБД свой собственный формат. Эти модели используются разработчиками СУБД.

Пример реляционной модели, основные термины. Реляционная модель описывает предметную область в виде совокупности взаимосвязанных таблиц. В теории множеств в таблице есть множество строк, которые называются отношением. Строки в данных терминах называются кортежами. Колонки – атрибутами. Элементом кортежа является значение атрибута. Таблица – отношение – файл. Строка – кортеж – запись. Колонка – атрибут – поле. Отношения отличаются от таблиц следующими свойствами: 1. В отношении нет одинаковых кортежей. 2. Порядок кортежей и атрибутов несущественен. 3. Каждый атрибут должен иметь уникальное имя. 4. Атрибут должен быть атомарным и однотипным. Пример. Отпуск товара со склада. В самом начале любой разработки необходимо сформулировать бизнес-правила, т.е. требования к системе: анонимные продажи неразрешены, каждый покупатель может приобрести множество товаров, одно наименование может быть заказано многими покупателями, покупатель размещает множество заказов и каждый заказ может состоять из множества товаров, цена и количество товара должно быть неотрицательно.

Customers

CustID

CustName

Address

1

2

3

Иванов

Петров

Сидоров

Москва

Москва

Воронеж

Требование различия кортежей приводит к понятию первичного ключа. Первичный ключ – атрибут или группа атрибутов однозначным образом идентифицирующие кортеж. Первичные ключи бывают двух видов: естественные и суррогатные. Естественный ключ – это какой-либо необходимый атрибут объекта. Искусственный суррогатный ключ – это обычно число, которое генерируется самим сервером или программой. В данном случае CustID – первичный ключ Primary Key – PK. В более широком смысле, ключ – это любой атрибут, который используется для сортировки или поиска. В отношении может быть несколько уникальных ключей, например номер паспорта, номер медицинского полиса, но только 1 из них объявлен как первичный. Индекс – структура, используемая для ускорения сортировки и поиска. По первичному ключу СУБД создает индексы автоматически.
^ Реляционные связи, примеры использования

3 вида реляционных связей: 1 к 1, 1 ко многим, многие ко многим. 1. означает: строке в 1 таблице всегда соответствует только 1 строка в другой. 2. строке в 1 таблице (родительская) может соответствовать несколько строк другой таблицы (дочерняя). Наиболее часто используется. 3. 1 строке может соответствовать множество строк и обратное тоже верно. Пример. Заказчик оставляет множество заказов. Преподаватель – предметы. Автор – книги. Связь 1:1 встречается редко.

OrdersPK

OrdID

FK

CustID

OrdDate

1

2

3

4

1

1

2

3

10.09.10

11.09.10

12.09.10

15.09.10

Ключ в дочерней таблице, указывающий на соответствующий ключ родительской называется внешним ключом Foreign Key (FK). Внешний ключ всегда должен совпадать с каким-либо первичным. Мертвые ссылки не допускаются. Связь между заказами и товарами – многие ко многим. В реляционной модели такие связи строятся введением дополнительной связующей таблицы, в которую входят первичные ключи двух главных таблиц в качестве внешних.

Products

ProdID

ProdName

Price

Rest

1

2

3

Opel

BMW

ZAZ

700

1000

150

5

3

1




OrdID

ProdID

ProdCount

1

1

2

3

1

2

3

1

1

1

1

2

Недостаток реляционной модели – отсутствие наглядности. Связь через ключи.

Другие проблемы при использовании внешних ключей: 1. Необходимость поддержания ссылочной целостности. Не должно быть мертвых ссылок. Решается средствами сервера БД. 2. Неинформативность внешних ключей. Решение: списки просмотра (все, что в таблице, должно быть выбрано, но не вбивается вручную; пользователь видит название, а номер подставляется). 3. Необходимость синхронизации (при выборе заказчика необходимо видеть все его заказы; при перемещении по заказчикам, заказы меняются). Решение: программные средства. 4. Выборка из нескольких таблиц при просмотре деталей заказа должна видеть не только коды, но и название. Решение: средства SQL (операция соединения таблиц). Сетевая и иерархическая модель сейчас не используются. Иерархическая модель: представляется в виде дерева данных, вершина – запись родительского объекта. Минус: Связь многие ко многим описать трудно; только для 1 ко многим. Плюс: наглядность. Сетевая модель. Более универсальна, БД в виде ориентированного графа. Недостаток – запутанность.
^ ER модель, сущности и атрибуты

Концептуальная модель, применяемая на ранних этапах проектирования. Преимущество – наглядность. Недостаток – для работы с данными должна быть преобразована в реляционную модель. Инструмент: компания СА, пакет All Function, компонент ERwin.ERwin может использовать несколько нотаций. IDEF 1X – схема по умолчанию. ERwin работает с двумя видами моделей: логической и физической. Логическая – не привязана к конкретной СУБД, обобщенный взгляд на предметную область. Допускаются русские имена и обозначения. Этапы: 1. Создание логической модели. 2. Преобразование в физическую (Oracle, SQLSqrver). Указать тип СУБД, типы данных для этой СУБД. 3. Прямое проектирование. Создание схемы БД на сервере, т.е. структуры. Схема: название таблицы, структура таблицы, первичные внешние ключи. Генерация всех возможных методанных программного кода, реализует бизнас-правила. ERwin как многоцелевая система должна знать все особенности СУБД. Слишком много возможностей. Уже запущен сервер – прописать путь. Создание скрипта (сохранение в txt файле, выполнение на сервере). Сущности и атрибуты. Сущность – тип объекта предметной области, информация о котором должна накапливаться и изучаться (заказчик). Экземпляр сущности – сам объект (Иванов). В реляционной теории: сущность – таблица, экземпляр – строка таблицы. Сущность описывается атрибутами (неделимая характеристика сущности). CustID – первичный ключевой атрибут, CustName – не ключевой атрибут. Для атрибутов необходимо указывать типы (числовой, графический, строковый).
^ Связи в ER моделях

Связи – логическое отношение между сущностями. Семантическая модель. Связи: идентифицирующие и не идентифицирующие, 1 ко многим, многие ко многим. Картинка. Внешние ключи переносятся и удаляются автоматически. Идентифицирующая – переносит первичный ключ родительской таблицы в состав первичный атрибутов дочерней и делает его внешним. Дочерняя сущность зависима, обозначается овалом. Зависимая сущность не имеет собственного РК, не может существовать без родительской сущности. Внешние ключи не обязательно уникальны. Зависимая имеет смысл только в контексте родительской, ее экземпляр не может существовать без экземпляра родительской сущности. Такую сущность можно рассматривать как «расширенный атрибут» родительской сущности. Не может существовать, т.к. первичные ключи не допускают значение Null. Связь называется идентифицирующей. Неидентифицирующая связь бывает обязательная и необязательная – внешний ключ в дочерней таблице может быть не заполнен. Связь многие ко многим. Связывает 2 родительские сущности, ключи не мигрируют. Рисуется только на логическом уровне модели. На физическом уровне она преобразуется, вводится промежуточная сущность, дочерняя по отношению к двум родительским. Валера на рекомендуэ!. Картинка. Если зависимая сущность, то она будет иметь составной первичный ключ. На практике это невозможно, т.к. 1 пациент 1 врача может посещать многократно. Промежуточную сущность называют ассоциативной. Для наглядности связь можно именовать. На окончаниях связи можно указать кратность – количество экземпляров дочерней сущности. 4 типа: 1. по умолчанию (1 экземпляр родительской соответствует ) экземпляров, 1 и много дочерних). 2. 1 экз род соответствует 1 или много экз доч (обозначается Р). 3. 0 или 1 (Z). 4. заданное число дочерних сущностей.
Рекурсивные связи, примеры

Встречаются ситуации, когда сущность связана сама с собой отношением 1 ко многим (рекурсия). Многие ко многим – сетевая рекурсия. Картинка. Первичный ключ мигрирует в состав других атрибутов с другим названием. Роль связей указывается на вкладке свойств связей.

ID

FIO

ManagerID

1

2

3

Иванов

Петров

Сидоров

2

2

1

У Петрова в подчинении Иванов, Петров сам себе начальник. Имя внешнего ключа принимает имя роли (можно переименовать). Сетевая рекурсия. Футбол. Сущность – команда. Картинка. 1 команда может играть с другой множество раз. Каждая связь имеет роль, поэтому внешние ключи переобозначены. 1 – Спартак, 2 – Зенит, 3 – ЦСКА.

OwnID

GuestID

Season

Score

1

2

1

2

1

2

2009

2009

2010

7:0

0:5

8:0


^ Иерархия наследования сущностей

Это тип связи между сущностями, имеющими общие атрибуты, например сотрудники организации будут нескольких видов – штатные, совместители, консультанты. У всех часть атрибутов общая, а часть различается. Поступают как в ООП: выделяют родительского предка – сотрудник, в котором будет общая для всех информация. Картинка.

СотрID

ФИО

Тип

1

2

3

Иванов

Петров

Сидоров

Штатный

Совместитель

Консультант

Штатные

СотрID

№книжки

Должность

1

…..

Инженер

Такая модель эквивалентна нескольким сущностям, связанным отношениями 1:1. Связь 1:1 строится введением первичного ключа родительской сущности в состав первичного дочернего. При этом он там остается единственным. Картинка. Иерархия наследования рисуется только на логическом уровне. На физическом она преобразуется в связи 1:1. Различают неполный и полный кластер подтипов. В случае полного набор дочерних сущностей содержит все возможные сущности. Картинка.
Этапы проектирования БД, жизненный цикл

1. Постановка задачи. Формулировка требований. 2. Формулировка бизнес-правил. Логика работы с данными. Ограничения на данные. 3. Создание ER схемы. 4. Привязка ER схемы к целевой СУБД. Уточнение модели (в терминах ERwin: порождение физической модели). 5. Генерация схемы БД, прямое проектирование. В соответствии с сущностями создается структура таблиц, определяются ключи и ограничения. Иногда, по желанию разработчика, генерируются хранимые процедуры и триггеры, реализующие бизнес-правило. Прямое проектирование в ERwin. 2 способа: 1. Настраивается соединение с БД и все таблицы и метаданные будут созданы автоматически. 2. На сервере создается пустой файл БД, в ERwin генерируется скрипт (сценарий), состоящий из операторов создания таблиц и метаданных. Можно просмотреть и сохранить скрипт в файле. Переходим с среду разработки сервера и этот скрипт выполняем (InterBase – служба IB Expert). Схема создана. 6. Проверка работоспособности системы, ввод текстовых данных в IB Expert. 7. Написание серверной части приложения, реализующей бизнес-правила. Хранимые процедуры и триггеры – серверная процедура, выполняется автоматически в ответ на событие. 8. Обработка типовых запросов данных. Выяснить, насколько наша БД отвечает запросам. 9. Написание клиентской части приложения. 10. Тестирование БД, всей системы. Заполнение информацией. 11. Внедрение и пробная эксплуатация. 12. Модернизация. 13. Снятие БД с эксплуатации.
DDL, таблицы, ограничения

DDL – часть языка SQL, структурированный язык запросов. Стандартов на SQL нет. Распространен SQL 9r. Стандартизированная: InterBase, FireBird. Оператор описания данных

create table <имя_таблицы> (

<определение_столбца>,

<определение_столбца>,



<определение_столбца>,

[<ограничения на таблицу>,



<ограничения на таблицу>]

);

Определение столбца:

<имя столбца> {<тип данных>|<домен>|compuited by (<выражение>) <атрибут>}

{} – выбор

Типы столбцов отличаются в разных СУБД. Примеры: float плавающая точка, decimal фиксированная точка, data календарный тип, включает время, blok произвольные данные в двоичном формате. Домен – пользовательский тип данных. Пример

Create table customers (

CustID integer NotNull,

Primary key,

CustName varChar (50) Not Null

Address varchar (50)

);

Кроме атрибута Not Null в определении столбца могут присутствовать 4 вида ограничений: 1. первичного ключа primary key, 2. внешнего ключа foreign key, 3. уникальности unig (столбец может принимать только несовпадающие значения). Либо primary key, либо unig, т.к. эти 2 ограничения несовместимы. 4. вводимый значения check (<логическое выражение>). Столбец принимает только те значения, для которых логическое выражение верно. Пример. Rest integer check (Rest>=0). 5. default <дополнительное значение>. Если не заполнили столбец, то он принимает указанное значение. Ограничения можно именовать и указывать на уровне таблицы – рекомендуемый вариант. На уровне таблицы следует объявлять ограничения, затрагивающие несколько столбцов.

Create table Customers (

CustID integer Not Null

[constraint pk Cust] // сами назвали

primary key (CustID)

);

Ограничения можно задавать отдельными модификатовати при моздании таблицы

Alter table <действие>

Alter table customers add (drop) //удаление ограничения

Constraint pk Cust primary key (CustID)
Alter table customers add column //добавить столбец

Phone varchar (20)
Drop <имя таблицы> //удалить таблицу целиком

Alter table Customers add constraint

Uq Address unique (Address)
Ограничения ссылочной целостности

Описываются для дочерней таблицы и состоят из объявления внешнего ключа и правил ссылочной целостности Referential Inteqraty, Referencec Rules. Наличие внешнего ключа в дочерней таблице не гарантирует целостности. Ограничения необходимо контролировать, либо определить на сервере базы данных следующим образом: на уровне таблицы имеет следующий вид.

[constraint <имя>] foreign key (столбец доч табл)

References <имя род табл> [(столбец род табл)]

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

[on delete [no action|cascade|set null| set default]]

[on update [no action|cascade|set null| set default]]

Если не указывать, то по умолчанию действуют on delete no action и on update no action. Например изменили первичный ключ в род табл, но с ним есть связанные записи в дочерних. No action запрещает изменение первичного ключа, если есть связанные записи. On delete пытаемся удалить запись из род табл (например заказчика), но есть его заказы. Запрещено удалять заказчика. Cascade разрешает удалять записи из род, но при этом требует удаления всех связанных из дочерней. Set Null означает, что в доч табл подставляется пустое значение внешнего ключа. Set default заставляет подставить значение по умолчанию, если оно определялось при создании таблицы. В любом случае ограничение внешнего ключа запрещает вставлять в доч табл значение, которого нет в родительской.

Create table Orders (

OrdID integer Not Null Primary key;



CustID: integer;



Constraint fk Cust

Foreign key (CustID)

References Customers

);
Создание доменов

Домен – это множество значений, из которых могут заполняться значения столбцов. Обычные названия типов также являются доменами (integer, real), но можно и явно указывать домены, объявляя в них всевозможные ограничения (check, default). Это удобно, если 1 такой сложный тип встречается во множестве таблиц.

^ Create domain <имя>

As <тип>

Default <значение>

[Not Null]

[check (<ограничения>)]
Пример

Create domain dMark

As integer null

Check (value in (2,3,4,5))
Create table exam (

Mark dMark,

….,

)
  1   2   3



Разместите кнопку на своём сайте:
Документы




База данных защищена авторским правом ©kiev.convdocs.org 2000-2013
При копировании материала обязательно указание активной ссылки открытой для индексации.
обратиться к администрации
Похожие:
Документы