Управление данными. Основы проектирования БД

1
Управление данными
Часть 5.
Основы проектирования
баз данных
(©) Владислав Лавров, vlavrov.com

2
это процесс разработки структуры
(схемы) базы данных (БД) в соответствии
с требованиями пользователей
Что такое проектирование базы данных ?

3
5.1. Основные требования
при проектировании базы данных

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

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

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

7
Установка защиты базы данных
от несанкционированного доступа

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

9
5.2. Основы классической
методологии проектирования
базы данных

10
Пользователь 1
Концептуальные
требования
Пользователь 2
Пользователь N
Внутренняя
модель
Прикладная программа 1Прикладная программа 1
Сервер БД
Прикладная программа 2Прикладная программа 2 Прикладная программа NПрикладная программа N
Таблица 1
Таблица 2
Таблица 3
Логическая модель
Таблица 1
Таблица 2
Таблица 3
Концептуальная модель
Внешняя модель Внешняя модель Внешняя модель. . .
. . .

11
Результаты проектирования базы данных
1. Полная структура базы данных
(концептуальная, логическая и
внутренняя модели).
2. Руководства для администраторов
базы данных и прикладных
программистов.

12
5.3. Жизненный цикл
системы баз данных

13
Фаза анализа и проектирования
1. Формулирование и анализ требований
2. Концептуальное проектирование
3. Проектирование реализации
4. Физическое проектирование
Фаза реализации и функционирования базы данных
1. Реализация базы данных
2. Анализ функционирования и поддержка
3. Модификация

14
5.4. Основные этапы
проектирования баз данных

15
Общие
информационные
Требования к обработке
Характеристики СУБД
Спецификации требований
Информационная
структура
Логическая структура базы
данных (СУБД-ориентированная)
и спецификации прикладных
программ
Физическая структура базы
данных
Характеристики
операционной системы и
аппаратно-технических
средств
Этап 2. Концептуальное
проектирование
Этап 3. Проектирование
реализации
Этап 4. Физическое
проектирование
Этап 1. Формулировка и анализ
требований

16
Этап 1. Формулирование и анализ требований
Этап 2. Концептуальное проектирование
Этап 3. Проектирование реализации
Этап 4. Физическое проектирование

17
Цель
Сбор, анализ и формализация требований,
предъявляемых к содержанию и процессу
обработки данных всеми известными и
потенциальными пользователями базы данных.

18
Результат
Техническое задание (ТЗ),
которое содержит:
– назначение,
– требования,
– ограничения,
– возможности,
– бизнес-процессы (функции),
– объем,
– смету затрат,
– сроки,
– показатели экономической эффективности,
– исполнители.

19
• Функциональный:
реализует принцип движения
«от задач» и применяется тогда,
когда заранее известны
функции некоторой группы лиц
и комплексов задач, для
обслуживания
информационных потребностей
которых создается
рассматриваемая БД.
Подходы к проектированию:
• Предметный:
информационные
потребности будущих
пользователей БД жестко не
фиксируются, они могут быть
многоаспектными и весьма
динамичными.

20
Общие требования при проектировании базы данных:
• многократное использование данных;
• простота, легкость использования;
• гибкость при модификации структуры;
• обработка незапланированных запросов;
• простота корректировки данных;
• небольшие затраты на эксплуатацию;
• минимальная избыточность;
• производительность;
• секретность;
• достоверность;
• защита от искажений и сбоев;
• физическая и логическая независимость;
• требуемая скорость доступа и поиска;
• стандартизация данных;
• наличие словаря базы;
• контроль за целостностью данных в базе;
• восстановление и реорганизация данных в базе.

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

22
• имя и описание объекта данных;
• элементы данных;
• продолжительность хранения
• условия перевода в архив.
Содержание исходной информации:

23
Пример содержания исходной информации

24
Пример функционального моделирования
(SADT-модель, начальный уровень модели)

25
Пример функционального моделирования
(SADT-модели, первый уровень декомпозиции модели)

26

27
Цель
Построение независимой от СУБД
информационной структуры путем объединения
информационных требований пользователей.
Результат
Концептуальная модель.

28
Пример концептуального моделирования
(ER-диаграммы)

29
1. Моделирование частных представлений пользователей с использованием
диаграмм «сущность - связь» (Entity-Relationship Diagrams, ER-диаграмм):
•определение сущностей;
•определение атрибутов сущностей;
•идентификация ключевых атрибутов сущностей;
•определение связей между сущностями.
2. Интеграция частных представлений:
Концептуальные требования отдельных пользователей, определенные
в стандартной форме (диаграммы «сущность-связь»), сливаются в
единое глобальное представление. При этом должны быть выявлены и
ликвидированы противоречивые и избыточные данные.
Метод выполнения :

30

31
Компоненты
• проектирование базы данных;
• проектирование программ

32
Цель
создание СУБД-ориентированной схемы
(логической модели) с использованием в качестве
исходных данных результатов концептуального
проектирования и требований обработки
конкретной СУБД.

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

34
Пример реализации даталогической модели
Фрагмент
даталогической
модели БД
Фрагмент
спецификации
таблиц БД

35
Показатели эффективности функционирования физической БД:
• Время ввода-вывода – время, затрачиваемое на выборку данных
с внешней памяти в оперативную, включая время передачи
данных.
• Время доступа – промежуток времени между выдачей команды,
содержащей обращение к некоторым данным, и фактическим
получением данных для обработки.
• Время отклика – промежуток времени между вводом запроса к
базе данных в компьютере и завершением обработки запроса с
представлением результатов.

36

37
Компоненты
• выбор физической структуры базы данных;
• уточнение спецификации программных
модулей

38
Цель
создание физической структуры базы данных и
набор реализуемых алгоритмов по ее
использованию в терминах конкретной СУБД

39
Результат
полностью готовая к внедрению структура базы
данных и набор реализуемых алгоритмов по ее
использованию

40
Категории проектных решений
• Проектирование формата хранимых записей.
• Анализ и проектирование кластеров.
• Проектирование путей доступа.

41
5.5. Обеспечение свойств базы данных в процессе
проектирования
Фундаментальные свойства базы данных
1) целостность, согласованность, восстанавливаемость;
2) безопасность;
3) эффективность, рост, размер, эксплуатационные ограничения.

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

43
Безопасность
Защита данных от преднамеренного или непреднамеренного
доступа, модификации или разрушения.
Эффективность
Степень соизмерения результатов функционирования базы
данных с затратами на обеспечение целостности базы данных.
Показатель – скорость обработки единицы информации

44
5.6. Даталогическое проектирования базы данных
Цель
разработка схемы базы данных, т.е. совокупности схем отношений
(таблиц), которые адекватно моделируют объекты (предметы,
явления и др.) предметной области и семантические связи между
этими объектами.
Результаты
• описание концептуальной схемы БД в терминах выбранной
СУБД;
• описание внешних моделей в терминах выбранной СУБД;
• описание правил поддержки целостности базы данных;
• разработка процедур поддержки семантической целостности

45
5.6.1. Проектирование реляционных баз данных
с использованием принципов нормализации
Проблемы :
1. Проблема логического проектирования.
Каким образом отобразить объекты предметной области в
абстрактные объекты модели данных, чтобы это отображение
не противоречило семантике предметной области и было по
возможности лучшим (эффективным, удобным и т.д.)?
2. Проблема физического проектирования.
Как обеспечить эффективность выполнения запросов к базе
данных, т.е. каким образом, имея в виду особенности
конкретной СУБД, расположить данные во внешней памяти,
создания каких дополнительных структур
(например, индексов) потребовать и т.д.?

46
Проектирование реляционных баз данных
Принимаемые решения:
• Из каких отношений должна состоять база данных?
• Каким образом должны быть связаны эти отношения?
• Какие атрибуты должны быть у этих отношений?

47
Методы проектирования схемы БД:
1. Декомпозиция (разбиение)
Исходное множество отношений, входящих в схему
БД, заменяется другим множеством отношений,
являющихся проекциями исходных отношений.
Общее количество отношений возрастает.
Таблица 1
Таблица 2
Таблица 3

48
Методы проектирования схемы БД:
2. Синтез (сборка)
Схема базы данных компонуется из заданных
исходных элементарных зависимостей между
объектами предметной области.
Общее количество отношений уменьшается.
Таблица 3
Таблица 1
Таблица 2

49
Теория нормализации
Цель
Сократить избыточность хранимых данных
Преимущества
• экономия объема используемой памяти;
• уменьшение затрат на многократные операции обновления
избыточных копий;
• устранение возможности возникновения противоречий из-за
хранения в разных местах сведений об одном и том же объекте.
Нормализация схем отношений
Формальный аппарат ограничений на формирование отношений
(таблиц), который позволяет устранить дублирование, обеспечивает
непротиворечивость хранимых в базе данных, уменьшает
трудозатраты на сопровождение (ввод, корректировку) базы данных.

50
Теория нормализации
Нормальные формы
• первая нормальная форма (1NF);
• вторая нормальная форма (2NF);
• третья нормальная форма (3NF);
• усиленная третья нормальная форма, или нормальная форма Бойса-
Кодда (BCNF);
• четвертая нормальная форма (4NF);
• пятая нормальная форма (5NF).
Свойства нормальных форм
• каждая следующая нормальная форма в некотором смысле лучше
предыдущей нормальной формы;
• при переходе к следующей нормальной форме свойства предыдущих
нормальных форм сохраняются.

51
Теория нормализации (основные определения)
Функциональная зависимость
Функциональной зависимостью набора атрибутов В отношения
R от набора атрибутов А того же отношения, обозначаемой как
R.A  R.B или А  В,
называется такое соотношение проекций R[A] и R[B],
при котором в каждый момент времени любому элементу
проекции R[A] соответствует только один элемент проекции
R[B], входящий вместе с ним в какой-либо кортеж отношения R.

52
Функциональная зависимость
СОТРУДНИКИ (Табельный_номер, ФИО, Номер_паспорта,
Номер_отдела, Наименование_отдела, Должность)
Пример функциональной зависимости:
Табельный_номер  ФИО, Номер_отдела,
Наименование_отдела, Должность
Функциональная взаимозависимость
Если одновременно существуют функциональные зависимости
вида А  В и B  А, тогда имеет место функциональная
взаимозависимость, которая изображается А  В.
Пример функциональной взаимозависимости
Табельный_номер  Номер_паспорта

53
Полная и неполная (частичная) функциональная
зависимость
Функциональная зависимость R.A  R.B называется полной, если набор
атрибутов В функционально зависит от А и не зависит функционально от
любого подмножества А, то есть если:
A1  A  R.A1 -/-> R.B.
Читается следующим образом: для любого A1, являющегося
подмножеством A, R.B функционально не зависит от R.A1, в противном
случае
зависимость R.A R.B называется неполной (частичной).
Примеры:
ЗАКАЗЫ (Номер_заказа, Код_товара,
КоличествоТовараВЗаказе, Наименование_товара)
Полная функциональная зависимость:
Номер_заказа, Код_товара  КоличествоТовараВЗаказе
Неполная функциональная зависимость:
Номер_заказа, Код_товара  Наименование_товара

54
Транзитивная функциональная зависимость
Функциональная зависимость R.A  R.B называется транзитивной,
если существует набор атрибутов С такой, что:
– С не является подмножеством А;
– С не включает в себя В;
– существует функциональная зависимость R.A  R.C ;
– не существует функциональной зависимости вида R.C  R.A,
т.е. R.C -/-> R.A ;
– существует функциональная зависимость R.C  R.B.
Примеры:
СОТРУДНИКИ (Номер_сотрудника, Код_отдела, Наименование_отдела, …)
Транзитивная функциональная зависимость:
Номер_сотрудника  Наименование_отдела
Атрибут Наименование_отдела транзитивно, через атритут Код_отдела зависит
от атрибута Номер_сотрудника, т.к. существуют зависимости
Код_отдела  Наименование_отдела,
Номер_сотрудника  Код_отдела

55
Ключевые атрибуты
Возможный ключ
Набор атрибутов отношения, который полностью и однозначно (функционально полно)
определяет значения всех остальных атрибутов отношения.
Другими словами, возможный ключ — это набор атрибутов, однозначно определяющий кортеж
отношения, в этом случае при удалении любого атрибута из этого набора его свойство
однозначной идентификации кортежа теряется.
Первичный ключ
Один из возможных ключей, выбранный для преимущественного использования в целях
однозначной идентификации значений всех остальных атрибутов отношения.
Неключевой атрибут
Любой атрибут отношения, не входящий в состав ни одного возможного ключа отношения.
Взаимно-независимые атрибуты
Атрибуты, которые не зависят функционально один от другого.

56
Пример: Система обеспечения продажи товаров (требования)
Номер заказа
(1234, 5678, 9112, ….)
Наименование товара
(AMD Athlon 64 X2 6000+ BOX < SocketAM2 >,
DDRII 2048 Mb (pc2-5300) 667MHz ECC Fully Buffered Qimonda,
D-Link DWA-140 Беспроводной адаптер USB, 802,11n, … )
Цена товара в заказе (…)
Количество товара в заказе (…)
Единицы измерения товара в заказе (шт., м, …)
Наименование типа товара
(процессоры, модули памяти, сетевое оборудование, …

57
Пример: Фрагмент системы обеспечения продажи товаров (исходный вариант)
Объект
ЗАКАЗЫ

58
Первая нормальная форма (1НФ)
Определение
Отношение находится в 1НФ (First Normal Form, 1NF) тогда и только
тогда, когда на пересечении каждого столбца и каждой строки находятся
только элементарные значения атрибутов.
Другими словами, в отношении не должно быть ячейки, в которой
находится несколько значений.
В терминах теории баз данных каждое значение в столбце таблицы
является элементарным (атомарным), т.е. состоящим из одного
экземпляра.
Пример
Фрагмент организации
данных, удовлетворяющий
условиям 1НФ

59
Аномалии первой нормальной формы
Аномалия включения
Пока не будет заказа на товар информация о товаре будет отсутствовать
в базе данных (наименование товара, код типа товара, наименование
типа товара);
Аномалия обновления
При изменении наименования товара необходим полный просмотр
отношения с целью найти все заказы, чтобы изменение наименования
товара было отражено во всех заказах.
Аномалия удаления
Если какой-либо товар удалить из базы данных (снят с продажи), то при
этом будет потеряна не только информация о тех заказах, в которых
присутствовал этот товар, но и товаре в целом (код товара, его
наименование и тип)
Аномалия дублирования
Некоторые значения атрибутов приходится многократно повторять
(наименование товара и наименование типа товара).

60
Вторая нормальная форма (2НФ)
Отношение находится во 2НФ (Second Normal Form, 2NF) тогда и только
тогда, когда оно находится в первой нормальной форме и не содержит
неполных функциональных зависимостей непервичных атрибутов от
атрибутов первичного ключа.
Другими словами, дополнительное ограничение состоит в том, что все
неключевые атрибуты целиком зависят от всего ключа, а не от отдельной
его части (т.е. отсутствует частичная зависимость).
Пример

61
Третья нормальная форма (3НФ)
Отношение находится в 3НФ (3НФ, Third Normal Form, 3NF) тогда и только тогда,
когда оно находится во второй нормальной форме и не содержит транзитивных
зависимостей.
Другими словами, дополнительное ограничение заключается в том, что все
неключевые атрибуты должны быть взаимно функционально независимы,
т.е. ни одно из неключевых полей таблицы не должно зависеть функционально от
любого другого неключевого поля.
Пример

62
5.7. Семантическое моделирование данных.
Диаграммы «сущность-связь»
Цель
Обеспечение разработчика информационной системы концептуальной
схемой базы данных в форме одной модели или нескольких локальных
моделей (внешних моделей), которые относительно легко могут быть
отображены в любую систему баз данных.
Польза для проектировщиков
– обсуждение с заказчиками, специалистами в предметной области;
– формализованное описание предметной области, которое легко «читается»
неспециалистами по базам данных;
– позволяет неспециалистам оценить глубину и корректность проработки
проекта БД;
– не привязано к конкретной СУБД.
Одной из наиболее распространенных семантических моделей данных является
модель «сущность–связь» (Entity–Relationship) или ER-модель (впервые была
предложена П.Ченом в 1976 г.)
Моделирование предметной области базируется на использовании графических
диаграмм, или ER-диаграмм (Entity–Relationship Diagrams).

63
5.7.1. Основные понятия семантического
моделирования данных
Сущность (Entity)
Реальный или представляемый объект (предмет или явление), имеющий
существенное значение для рассматриваемой предметной области
и о котором необходимо хранить информацию.
Пример
Графическое изображение сущностей на ER-диаграмме

64
Основные понятия семантического
моделирования данных (продолжение)
Связь (Relationship)
Именованная бинарная ассоциация, функциональная зависимость между
двумя сущностями, значимая для рассматриваемой предметной области.
В этом случае каждый экземпляр одной сущности ассоциирован с
произвольным (в том числе и нулевым) количеством экземпляров второй
сущности и наоборот.
Пример
Изображение степени и обязательности связи
Связь между сущностями «Технологические процессы» и «Технологические агрегаты»

65
Атрибут (Attribute)
Любая характеристика сущности, значимая для рассматриваемой
предметной области и предназначенная, в общем случае,
для классификации, идентификации, количественной характеристики и
выражения состояния сущности.
Атрибут выражает некоторое отдельное, интересующее пользователя
свойство сущности, которое характеризует ее экземпляр.
Отдельный атрибут определяется типом (числовой, текстовый,
логический, временной и др.), а также значением, которое он
принимает.
Основные понятия семантического
моделирования данных (продолжение)

66
Сущность (Entity):
• независимая от идентификаторов
каждый экземпляр сущности может быть однозначно идентифицирован
без определения его отношений с другими сущностями.
• зависимая от идентификаторов
однозначная идентификация экземпляра сущности зависит от его отношения
к другой сущности.
5.7.2. Методология IDEF 1X (Icam DEFinition)
Пример независимой от идентификатора сущностей
Коксовые
батареи
Доменные
печи
Пример зависимой от идентификатора сущностей
Выпуски
чугуна
Химические
анализы кокса

67
Методология IDEF 1X (Icam DEFinition) (продолжение)
Связь (Relationship)
Ассоциация между сущностями, при которой каждый экземпляр одной
сущности, называемой родительской сущностью, ассоциирован с
произвольным (в том числе и нулевым) количеством экземпляров
второй сущности, называемой сущностью-потомком, или дочерней
сущностью, а каждый экземпляр сущности-потомка ассоциирован в
точности с одним экземпляром сущности-родителя.
Экземпляр сущности-потомка может существовать только при
существовании сущности-родителя.
Графическое изображение мощности связи
в методологии IDEF 1X:
а – нуль, один или более;
б – один или много (P);
в – нуль или один (Z);
г – мощность в точности равна
некоторому положительному числу (N)

68
Виды связи в методологии IDEF1X
Идентифицирующая связь
Экземпляр сущности-потомка однозначно определяется своей связью
с сущностью-родителем
Пример
идентифицирующей
связи

69
Виды связи в методологии IDEF1X
Неидентифицирующая связь
Экземпляр сущности-потомка не определяется однозначно своей
связью с сущностью-родителем
Пример
неидентифицирующей
связи
Номер КБ (FK)

70
5.8. Информационное моделирование
с помощью CASE-средств
CASE-технология (Computer Aided System Engineering)
Представляет собой методологию проектирования информационных систем, а также
набор инструментальных средств, позволяющих в наглядной форме моделировать
предметную область, анализировать эту модель на всех этапах разработки и
сопровождения информационной системы и разрабатывать приложения в
соответствии с информационными потребностями пользователей.
Инструментальные CASE-средства
Программные средства, поддерживающие процессы создания и сопровождения
информационных систем, которые в общем случае включают следующие этапы:
– анализ и формулировку требований предметной области;
– проектирование баз данных и прикладного программного обеспечения;
– генерацию кода для выбранной СУБД и языка приложений;
– тестирование;
– документирование;
– обеспечение требуемого качества работы информационной системы и др.

71
5.8.1. Общая характеристика программы
AllFusion ERwin Data Modeler (ранее ERwin)
Назначение
Средство концептуального моделирования базы данных
Возможности
– Создание визуального представления (концептуальной модели
данных) для решаемой задачи в виде ER-диаграмм;
– Генерация концептуальной модели в различные сетевые
реляционные СУБД и настольные базы данных;
– Обратное проектирование (реинжиниринг) баз данных, т.е.
преобразование физической модели базы данных в
концептуальную модель, не привязанную к конкретной СУБД.
Уровни представления моделей
– Логический уровень (прямое отображение фактов сущностей из
реальной жизни);
– Физический уровень (использование конкретной целевой СУБД,
определены типы данных, индексы для таблиц и др.

72
5.8.2. Этапы построения информационной модели
в ERwin
1. Определение сущностей;
2. Определение связей (зависимостей) между сущностями;
3. Задание первичных и составных (альтернативных) ключей;
4. Определение атрибутов сущностей;
5. Приведение модели к требуемому уровню нормальной формы;
6. Переход к физическому описанию модели: назначение соответствий имя
сущности – имя таблицы, атрибут сущности – атрибут таблицы; задание
ограничений предметной области;
7. Генерация базы данных, т.е. формирование физической схемы для
конкретной выбранной (целевой) СУБД.

73
Логическое отображение модели в ERwin

74
Физическое отображение модели в ERwin

75
Настройка свойств связи между сущностями в ERwin

76
Построение информационной модели в ERwin
Этап 4. Определение
атрибутов сущностей
связей между
сущностями
сущностей
Этап 3. Задание
первичных ключей

77
Этап 5. Приведение модели к требуемому уровню нормальной формы
1. Проанализировать схему на присутствие сущностей, которые скрыто моделируют
несколько разных взаимосвязанных классов объектов реального мира (именно это
соответствует ненормализованным отношениям).
Если такое выявлено, то разделить каждую из этих сущностей на несколько новых
сущностей и установить между ними соответствующие связи.
Полученная схема будет находиться в первой нормальной форме.
2. Проанализировать все сущности, имеющие составные первичные ключи, на наличие
неполных функциональных зависимостей непервичных атрибутов от атрибутов
возможного ключа.
Если такие зависимости обнаружены, то разделить данные сущности на две,
определить для каждой сущности первичные ключи и установить между ними
соответствующие связи.
Полученная схема будет находиться во второй нормальной форме.
3. Проанализировать неключевые атрибуты всех сущностей на наличие транзитивных
функциональных зависимостей.
При обнаружении таковых расщепить каждую сущность на несколько таким
образом, чтобы ликвидировать транзитивные зависимости.
Схема находится в третьей нормальной форме.

78
Этап 5. Приведение модели к требуемому уровню нормальной формы
Инструмент
разрешения
связей
«многие-ко-
многим»
Окно
корректировки
связей между
сущностями
Область
настройки
установок
мощности
связи
Редактируемая
связь

79
Этап 6. Переход к физическому описанию модели
Выбор физического уровня
представления модели
Меню выбора
целевой СУБД
Окно выбора
целевой СУБД

80
Этап 7. Генерация базы данных Меню генерации
Кнопка генерации
Окно подключения к базе
данных на сервере
MS SQL Server 2000

Управление данными. Основы проектирования БД

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Andere mochten auch

Andere mochten auch (20)

Ähnlich wie Управление данными. Основы проектирования БД

Ähnlich wie Управление данными. Основы проектирования БД (20)

Mehr von Ural Federal University named after First President of Russia B.N. Yeltsin

Mehr von Ural Federal University named after First President of Russia B.N. Yeltsin (20)

Управление данными. Основы проектирования БД