До появления баз данных каждая программа хранила свои собственные плоские файлы — по одному файлу на программу. Представьте магазин. Программа продаж, программа выставления счетов и программа доставки…
English narration · English + 中文 subtitles burned in · Английское озвучивание · Английский + китайские субтитры (встроенные)
8.1
File-based storage and its limits · Хранение на основе файлов и его ограничения
Syllabus · Программа
English
Candidates should be able to:
Notes and guidance
Show understanding of the limitations of using a file-based approach for the storage and retrieval of data
Describe the features of a relational database that address the limitations of a file-based approach
Show understanding of and use the terminology associated with a relational database model
Использовать диаграмму «сущность–связь» (E-R) для документирования проектирования базы данных
Проявить понимание процесса нормализации
Первая нормальная форма (1NF), Вторая нормальная форма (2NF) и Третья нормальная форма (3NF)
Объяснить, почему заданный набор таблиц баз данных находится или не находится в 3NF
Создать нормализованную структуру базы данных по описанию БД, заданному набору данных или заданному набору таблиц
Source: Cambridge International syllabus · Источник: Программа Cambridge International
English
Before databases, programs stored data in flat files 平面文件 — usually one file per program. This is fine for small data but breaks down at scale.
Limitations
data redundancy 数据冗余 — the same data (a customer's address) is held in several files, one per program, so storage is wasted and every copy must be updated.
data inconsistency 数据不一致 — when one copy is updated and another is not, the files disagree and nobody knows which is right.
data dependence — each program is written for the exact layout of its files; change a field's length or add a field and every program that reads the file must be rewritten.
no shared access — a file is locked while one program uses it, so users cannot work on the data at the same time.
weak integrity 完整性 — no central rules stop an invalid value or a link to a customer who does not exist; weak security — access is per file, not per field; and queries across files need a new program each time.
A relational database 关系数据库 fixes these by storing data in tables managed by one piece of software (the DBMS) that all programs use.
Why a relational database is better — the three-mark answer. Each item of data is stored once, in one table, and tables are linked by keys, so there is no redundancy and no inconsistency; the data is independent of the programs, which ask the DBMS for what they need and are unaffected when the structure changes; and the DBMS enforces integrity rules, controls access per user and per field, allows many users at once, and answers any query without a new program being written.
Worked example. A repair shop stores its customers, devices and repair jobs using a file-based approach, one file per program. Give three problems this causes, and describe how a relational database would remove them.
The customer's name and phone number are stored in the repairs file and the invoices file (redundancy); when a customer changes number, one file is updated and the other is not (inconsistency); and when the shop wants a new report — repairs per technician — a new program has to be written to read the files (no ad-hoc queries). In a relational database the customer is stored once in a CUSTOMER table and referred to by CustomerID from the REPAIR table, so a change is made once and is seen everywhere; the report is a single SQL query.
Русский
До появления баз данных программы хранили данные в плоских файлах — обычно по одному файлу на программу. Это приемлемо для небольших объемов данных, но не работает при масштабировании.
Хранение на основе файлов размещает данные в отдельных файлах, как документы в картотеке — их трудно искать, и они легко дублируются
Ограничения
избыточность данных — одни и те же данные (адрес клиента) хранятся в нескольких файлах, по одному на программу; это приводит к потере места на диске, и каждую копию необходимо обновлять.
несогласованность данных — когда одна копия обновлена, а другая нет, файлы содержат противоречащие друг другу сведения, и невозможно определить, какая информация верна.
зависимость от данных — каждая программа написана под конкретную структуру своих файлов; изменение длины поля или добавление нового поля требует переписывания всех программ, читающих этот файл.
отсутствие общего доступа — файл блокируется во время использования одной программой, поэтому пользователи не могут одновременно работать с данными.
слабая целостность — отсутствуют централизованные правила, предотвращающие ввод невалидных значений или ссылок на несуществующих клиентов; слабая безопасность — доступ осуществляется на уровне файла, а не отдельного поля; запросы к данным из разных файлов требуют создания новой программы каждый раз.
Подход на основе файлов: каждая программа хранит свои собственные файлы
Реляционная база данных устраняет эти проблемы, храня данные в таблицах, управляемых одним программным обеспечением (СБД), которое используют все программы.
Подход на основе баз данных: одна СБД обслуживает все программы
Почему реляционная база данных лучше — ответ на три балла. Каждый элемент данных хранится один раз в одной таблице, а таблицы связаны ключами, поэтому отсутствует избыточность и несогласованность; данные независимы от программ, которые запрашивают у СБД необходимое и не страдают при изменении структуры; СБД обеспечивает соблюдение правил целостности, управляет доступом для каждого пользователя и каждого поля, позволяет множеству пользователей работать одновременно и отвечает на любые запросы без написания новой программы.
Разобранное решение примера. Магазин по ремонту техники хранит информацию о клиентах, устройствах и ремонтах с использованием подхода на основе файлов, по одному файлу на программу. Назовите три проблемы, которые это вызывает, и опишите, как реляционная база данных устранила бы их.
Имя и телефон клиента хранятся в файле ремонтов и в файле счетов (избыточность); при изменении номера телефона обновляется один файл, а другой остается старым (несогласованность); когда магазину нужен новый отчет — например, количество ремонтов на одного техника, — приходится писать новую программу для чтения файлов (нет возможности создавать запросы на лету). В реляционной базе данных клиент хранится один раз в таблице CUSTOMER и ссылается через CustomerID из таблицы REPAIR, поэтому изменения вносятся один раз и видны везде; отчет формируется одним SQL-запросом.
Relational model — terms · Реляционная модель — терминология
English
table 表 (relation) — a grid of rows and columns; one table per type of entity 实体 (e.g. CUSTOMER).
record 记录 (row, also called a tuple 元组) — one row; one instance of the entity.
field 字段 (column, also called an attribute 属性) — one column; one piece of information about each record.
primary key 主键 — a field (or fields) that uniquely identifies each record; never null or duplicated.
foreign key 外键 — a field whose value matches the primary key of another table, linking the two.
composite key 复合键 — a primary key made of two or more fields together.
candidate key 候选键 — any field(s) that could be the primary key.
secondary key 次键 — a non-primary field that is indexed for fast searching.
indexing 索引 — building an index on a field so look-ups and joins run faster.
referential integrity 参照完整性 — every foreign-key value must match an existing primary key (no orphan records).
A table is written in shorthand with the primary key underlined and foreign keys noted:
Worked example. State what is meant by entity, primary key and referential integrity in a relational database, and complete the term ↔ description table for tuple and attribute.
An entity is something about which data is stored — a person, object or event — which becomes one table. A primary key is the attribute (or combination of attributes) that uniquely identifies each record in a table. Referential integrity means that every foreign-key value must match the value of a primary key in the table it refers to, so a record cannot refer to one that does not exist. A tuple is one row of a table (one record); an attribute is one column (one field). Learn the pairs: table/relation, record/tuple, field/attribute.
Русский
таблица (отношение) — сетка строк и столбцов; одна таблица для каждого типа сущности (например, CUSTOMER).
запись (строка, также называемая кортежем) — одна строка; один экземпляр сущности.
поле (столбец, также называемый атрибутом) — один столбец; одно свойство информации о каждой записи.
первичный ключ — поле (или набор полей), которое уникально идентифицирует каждую запись; не может быть пустым (null) или дублироваться.
внешний ключ — поле, значение которого совпадает с первичным ключом другой таблицы, связывая две таблицы между собой.
составной ключ — первичный ключ, состоящий из двух или более полей вместе взятых.
кандидатский ключ — любое поле (или набор полей), которое могло бы стать первичным ключом.
вторичный ключ — поле, не являющееся первичным, но проиндексированное для быстрого поиска.
индексирование — создание индекса на поле для ускорения операций поиска и соединения таблиц.
ссылочная целостность — каждое значение внешнего ключа должно соответствовать существующему первичному ключу (отсутствуют «осиротевшие» записи).
Таблица записывается в сокращенном виде с подчеркиванием первичного ключа и отметкой внешних ключей:
CUSTOMER(CustomerID, Name, Phone)
ORDER(OrderID, CustomerID, OrderDate) -- CustomerID is FK → CUSTOMER
Внешний ключ связывает две таблицы: ORDER.CustomerID совпадает с первичным ключом CUSTOMER.CustomerID
Разобранное решение примера. Объясните, что означают сущность, первичный ключ и ссылочная целостность в реляционной базе данных, а также заполните таблицу соответствия «термин ↔ описание» для понятий кортеж и атрибут.
Сущность — это объект, для которого хранятся данные (человек, предмет или событие), который становится отдельной таблицей. Первичный ключ — это атрибут (или комбинация атрибутов), уникально идентифицирующий каждую запись в таблице. Ссылочная целостность означает, что каждое значение внешнего ключа должно соответствовать значению первичного ключа в той таблице, на которую оно ссылается, поэтому запись не может ссылаться на несуществующую. Кортеж — это одна строка таблицы (одна запись); атрибут — это один столбец (одно поле). Выучите пары: таблица/отношение, запись/кортеж, поле/атрибут.
Explore · Исследовать
Read a relational table with SELECT · Чтение реляционной таблицы с помощью SELECT
A relational table is just rows (records) and columns (fields). WHERE keeps the rows that match a condition; SELECT then keeps only the columns you asked for. · Реляционная таблица состоит из строк (записей) и столбцов (полей). WHERE оставляет строки, соответствующие условию; SELECT оставляет только запрошенные столбцы.
An entity-relationship diagram 实体关系图 shows the structure: each entity is a rectangle, each relationship a line, with the cardinality 基数 marked at each end:
one-to-one (1:1).
one-to-many 一对多 (1:M) — each Customer has many Orders; each Order has one Customer.
many-to-many (M:N) — Students take many Courses, and Courses have many Students.
A many-to-many relationship cannot be stored directly. Break it into two one-to-many relationships through a link table 连接表 holding the two foreign keys:
Drawing the E-R diagram for a given set of tables. Each table becomes an entity. A relationship exists wherever one table holds a foreign key to another; it runs from the table holding the foreign key (the many end) to the table whose primary key it is (the one end). A table with two foreign keys and no other identity is usually a link table resolving a many-to-many relationship. Label each line with the relationship type.
Worked example. A repair shop has the tables CUSTOMER(CustomerID, Name, Phone), DEVICE(DeviceID, CustomerID, Type, Model), TECHNICIAN(TechnicianID, Name) and REPAIR(RepairID, DeviceID, TechnicianID, RepairDate, Cost). Identify the relationships and their types.
DEVICE holds CustomerID, so CUSTOMER–DEVICE is one-to-many (one customer, many devices). REPAIR holds DeviceID, so DEVICE–REPAIR is one-to-many; it also holds TechnicianID, so TECHNICIAN–REPAIR is one-to-many. There is no direct CUSTOMER–REPAIR line: the link runs through DEVICE. Three lines, three crow's feet, all at the REPAIR or DEVICE ends.
Русский
Диаграмма «сущность-связь» показывает структуру: каждая сущность обозначается прямоугольником, каждая связь — линией, с указанием кардинальности на каждом конце:
«один-к-одному» (1:1).
один-ко-многим (1:M) — у каждого Клиента много Заказов; каждый Заказ принадлежит одному Клиенту.
многие-ко-многим (M:N) — Студенты посещают множество Курсов, а Курсы имеют множество Студентов.
Схема «сущность-связь»: один класс имеет многих студентовСимволы «вороньей лапки» для обозначения кардинальности связи
Связь многие-ко-многим нельзя сохранить напрямую. Разбейте её на две связи один-ко-многим через связующую таблицу, содержащую два внешних ключа:
ENROLMENT(StudentID, CourseID, EnrolmentDate)
Связующая таблица преобразует связь многие-ко-многим в две связи один-ко-многим
Построение схемы «сущность-связь» по набору таблиц. Каждая таблица становится сущностью. Существование связи определяется там, где одна таблица содержит внешний ключ на другую; линия идёт от таблицы, содержащей внешний ключ (конец многих), к таблице, являющейся носителем первичного ключа (конец одного). Таблица с двумя внешними ключами и без другой идентичности обычно является связующей таблицей, разрешающей связь многие-ко-многим. Подпишите каждую линию типом связи.
Построение диаграммы из таблиц: каждый внешний ключ представляет собой связь один-ко-многим, при этом конец «многих» находится в таблице, содержащей этот ключ
Разобранный пример. Мастерская по ремонту имеет таблицы CUSTOMER(CustomerID, Name, Phone), DEVICE(DeviceID, CustomerID, Type, Model), TECHNICIAN(TechnicianID, Name) и REPAIR(RepairID, DeviceID, TechnicianID, RepairDate, Cost). Определите связи и их типы.
DEVICE содержит CustomerID, поэтому CUSTOMER–DEVICE — это связь один-ко-многим (один клиент, много устройств). REPAIR содержит DeviceID, поэтому DEVICE–REPAIR — это связь один-ко-многим; она также содержит TechnicianID, поэтому TECHNICIAN–REPAIR — это связь один-ко-многим. Прямой линии CUSTOMER–REPAIR нет: связь проходит через DEVICE. Три линии, три «вороньи лапки», все находятся на концах REPAIR или DEVICE.
Normalisation 规范化 organises tables to cut redundancy and inconsistency, going through normal forms 范式 in order.
First normal form (1NF) — every field holds a single (atomic 原子) value, with no repeating groups, and a primary key.
Second normal form (2NF) — in 1NF, and every non-key field depends on the whole primary key (only matters for a composite key).
Third normal form (3NF) — in 2NF, and every non-key field depends only on the primary key, not on another non-key field (no transitive dependency 传递依赖).
A 3NF design stores each fact once, so insert/update/delete anomalies disappear. The trade-off is more tables and more joins. Aim for 3NF.
To produce a 3NF design: find the entities and their attributes; choose a primary key for each; split repeating/non-atomic fields (1NF); split fields depending on part of a composite key (2NF); split fields depending transitively on the key (3NF); add foreign keys for the relationships.
Worked example. The table ORDER(OrderID, CustomerID, CustomerName, ProductID, Quantity) has the composite primary key (OrderID, ProductID). Normalise it to 3NF. Test each non-key field against the key. Quantity depends on bothOrderID and ProductID, which is fine. But CustomerID depends on OrderID alone - only part of the composite key. That is a partial dependency, so the table is not in 2NF. Split it into ORDER_LINE(OrderID, ProductID, Quantity) and ORDER(OrderID, CustomerID, CustomerName). Now test 3NF: in that new ORDER table, CustomerName depends on CustomerID, which is not the key - a transitive dependency. Split again: ORDER(OrderID, CustomerID) and CUSTOMER(CustomerID, CustomerName). Name the dependency that breaks each form (partial breaks 2NF, transitive breaks 3NF); "it has repeated data" describes the symptom and earns nothing.
The three questions to ask of any table.Is every cell a single value, with no repeating group? If not, it is not in 1NF. If the key is composite, does every non-key field depend on the whole key? If some field depends on part of it, there is a partial dependency 部分依赖 and the table is not in 2NF. Does every non-key field depend on the key alone? If a field depends on another non-key field, there is a transitive dependency and the table is not in 3NF. An "explain why the table is not in 3NF" answer names the dependency and the fields involved.
Worked example. A car-rental shop records each rental as RENTAL(RentalID, RentalDate, CustomerID, CustomerName, CustomerPhone, CarReg, CarModel, DailyRate, Days), where one rental can include several cars. Explain why the table is not normalised and produce a 3NF design.
Not in 1NF: the car fields CarReg, CarModel, DailyRate, Days form a repeating group — one rental has several cars. Move them to RENTAL_CAR(RentalID, CarReg, CarModel, DailyRate, Days) with the composite key (RentalID, CarReg). Not in 2NF: in RENTAL_CAR, CarModel and DailyRate depend on CarReg alone — a partial dependency. Move them to CAR(CarReg, CarModel, DailyRate), leaving RENTAL_CAR(RentalID, CarReg, Days). Not in 3NF: in RENTAL, CustomerName and CustomerPhone depend on CustomerID, a non-key field — a transitive dependency. Move them to CUSTOMER(CustomerID, CustomerName, CustomerPhone), leaving RENTAL(RentalID, RentalDate, CustomerID). The 3NF design is four tables — CUSTOMER, RENTAL, RENTAL_CAR, CAR — with CustomerID, RentalID and CarReg as foreign keys; underline every primary key.
Русский
Нормализация упорядочивает таблицы для сокращения избыточности и несогласованности, последовательно проходя нормальные формы.
Первая нормальная форма (1NF) — каждое поле содержит одно (атомарное) значение, без повторяющихся групп, и имеется первичный ключ.
Вторая нормальная форма (2NF) — выполнение условий 1NF, и каждое неключевое поле зависит от целого первичного ключа (важно только для составного ключа).
Третья нормальная форма (3NF) — выполнение условий 2NF, и каждое неключевое поле зависит только от первичного ключа, а не от другого неключевого поля (отсутствие транзитивной зависимости).
Проект в 3NF хранит каждый факт один раз, поэтому исчезают аномалии вставки/обновления/удаления. Компромисс заключается в большем количестве таблиц и соединений. Стремитесь к 3NF.
Для получения проекта в 3NF: определите сущности и их атрибуты; выберите первичный ключ для каждой; разделите повторяющиеся/неатомарные поля (1NF); разделите поля, зависящие от части составного ключа (2NF); разделите поля, транзитивно зависящие от ключа (3NF); добавьте внешние ключи для связей.
Нормализация устраняет избыточность путем вынесения повторяющихся данных в отдельную таблицу
Разобранный пример. Таблица ORDER(OrderID, CustomerID, CustomerName, ProductID, Quantity) имеет составной первичный ключ (OrderID, ProductID). Нормализуйте её до 3NF. Проверьте каждое неключевое поле относительно ключа. Quantity зависит от обоихOrderID и ProductID, что допустимо. Но CustomerID зависит от OrderID только - лишь от части составного ключа. Это частичная зависимость, поэтому таблица не находится в 2NF. Разделите её на ORDER_LINE(OrderID, ProductID, Quantity) и ORDER(OrderID, CustomerID, CustomerName). Теперь проверьте 3NF: в новой таблице ORDER поле CustomerName зависит от CustomerID, которое не является ключом - это транзитивная зависимость. Разделите снова: на ORDER(OrderID, CustomerID) и CUSTOMER(CustomerID, CustomerName). Назовите зависимость, нарушающую каждую форму (частичная нарушает 2NF, транзитивная нарушает 3NF); фраза «в ней есть повторяющиеся данные» описывает симптом и не оценивается баллами.
Три вопроса для проверки любой таблицы.Является ли каждая ячейка единственным значением, без повторяющейся группы? Если нет, то таблица не находится в 1NF. Если ключ составной, зависит ли каждое неключевое поле от всего ключа? Если какое-либо поле зависит от его части, существует частичная зависимость, и таблица не находится в 2NF. Зависит ли каждое неключевое поле только от ключа? Если поле зависит от другого неключевого поля, существует транзитивная зависимость, и таблица не находится в 3NF. Ответ на вопрос «объясните, почему таблица не находится в 3NF» должен называть зависимость и涉及的的字段 (поля, участвующие в ней).
Разобранный пример. Магазин проката автомобилей регистрирует каждую аренду как RENTAL(RentalID, RentalDate, CustomerID, CustomerName, CustomerPhone, CarReg, CarModel, DailyRate, Days), где одна аренда может включать несколько машин. Объясните, почему таблица не нормализована, и создайте проект в 3NF.
Не соответствует 1НФ: поля CarReg, CarModel, DailyRate, Days образуют повторяющуюся группу — у одной аренды несколько автомобилей. Переместите их в RENTAL_CAR(RentalID, CarReg, CarModel, DailyRate, Days) с составным ключом (RentalID, CarReg). Не соответствует 2НФ: в RENTAL_CAR, CarModel и DailyRate значения зависят только от CarReg — это частичная зависимость. Переместите их в CAR(CarReg, CarModel, DailyRate), оставив RENTAL_CAR(RentalID, CarReg, Days). Не соответствует 3НФ: в RENTAL, CustomerName и CustomerPhone значения зависят от CustomerID,非ключавого поля — это транзитивная зависимость. Переместите их в CUSTOMER(CustomerID, CustomerName, CustomerPhone), оставив RENTAL(RentalID, RentalDate, CustomerID). Дизайн в 3НФ включает четыре таблицы — CUSTOMER, RENTAL, RENTAL_CAR, CAR — с CustomerID, RentalID и CarReg в качестве внешних ключей; подчеркните каждый первичный ключ.
Data Definition Language/ˈdeɪtə ˌdefɪˈnɪʃn ˈlæŋɡwɪdʒ/
Язык определения данных
Data Manipulation Language/ˈdeɪtə məˌnɪpjʊˈleɪʃn ˈlæŋɡwɪdʒ/
Язык манипулирования данными
aggregate functions/ˈæɡrɪɡeɪt ˈfʌŋkʃnz/
агрегатные функции
8.2
Database Management System (DBMS) · Система управления базами данных (СУБД)
Syllabus · Программа
English
Candidates should be able to:
Notes and guidance
Show understanding of the features provided by a Database Management System (DBMS) that address the issues of a file based approach
Including: • data management, including maintaining a data dictionary • data modelling • logical schema • data integrity • data security, including backup procedures and the use of access rights to individuals / groups of users
Show understanding of how software tools found within a DBMS are used in practice
Including the use and purpose of: • developer interface • query processor
Русский
Кандидаты должны уметь:
Примечания и рекомендации
Проявить понимание функций, предоставляемых Системой управления базами данных (СУБД), которые решают проблемы файлового подхода
Включая: • управление данными, включая ведение словаря данных • моделирование данных • логическая схема • целостность данных • безопасность данных, включая процедуры резервного копирования и использование прав доступа для отдельных лиц / групп пользователей
Проявить понимание того, как на практике используются инструменты программного обеспечения внутри СУБД
Включая использование и назначение: • интерфейса разработчика • процессора запросов
Source: Cambridge International syllabus · Источник: Программа Cambridge International
English
A DBMS 数据库管理系统 manages the database centrally. Features that fix the file-based limits:
data dictionary 数据字典 — a description of every table, field, type and key; programs query it instead of hard-coding the structure.
redundancy/consistency control — each fact stored once.
concurrent access 并发访问 control — locks and transactions let many users work at once.
backup 备份 and recovery; security and per-user permissions.
integrity rules — keys, unique and range constraints, enforced centrally.
transactions 事务 — a group of operations that all succeed or all fail.
views 视图 — virtual tables that show each user "their" slice of the data.
data management 数据管理 and data modelling 数据建模 — control how data is stored and define its structure as a logical schema 逻辑模式 (the logical design, independent of physical storage).
data integrity 数据完整性 and data security 数据安全 — enforce correctness and control access centrally.
a query processor 查询处理器 runs queries; a developer interface 开发者接口 gives tools and APIs for building applications.
Its tools include a data-dictionary editor, a query builder, a forms builder, a report generator, user management, and an SQL editor.
What the data dictionary holds (a "give three items" question): the names of the tables; the names of the fields in each table; each field's data type and length; the primary and foreign keys and the relationships between tables; validation rules; indexes; and who may access each table. It is metadata — data about the data — and the DBMS uses it to check every query and every change.
How the DBMS keeps the data secure (a "describe two methods" question): authentication 身份验证 — a username and password, or a biometric, before any access; access rights — each user or group is allowed to read, write or delete only certain tables or fields, often through a view; encryption of the stored data and of data sent to it, so a copied file is unreadable; backups taken regularly, so the data can be restored after loss; and a transaction log that records who changed what.
The two software tools. The developer interface is what a programmer uses to build the database and the applications on it: create tables and set keys and validation, write queries and SQL, and design forms and reports, without knowing how the data is physically stored. The query processor takes a query (SQL from a program, or a query built in the interface), checks it against the data dictionary, works out the most efficient way to run it, retrieves the data and returns the results.
Logical schema. The DBMS keeps the logical design (which tables and fields exist and how they relate) separate from the physical storage (files, indexes, disk blocks). Programs work with the logical schema, so the physical storage can be reorganised without changing a single program — this is the data independence the file-based approach lacked.
Русский
СУБД централизованно управляет базой данных. Функции, устраняющие ограничения файлового подхода:
словарь данных — описание каждой таблицы, поля, типа и ключа; программы обращаются к нему вместо жесткого кодирования структуры.
контроль избыточности/согласованности — каждый факт хранится один раз.
контроль совместного доступа — блокировки и транзакции позволяют множеству пользователей работать одновременно.
резервное копирование и восстановление; безопасность и разрешения на уровне пользователя.
правила целостности — ключи, уникальность и диапазоны ограничений, enforce centrally.
транзакции — группа операций, которые либо все выполняются, либо ни одна не выполняется.
представления (виды) — виртуальные таблицы, показывающие каждому пользователю «его» часть данных.
управление данными и моделирование данных — управление способом хранения данных и определение его структуры как логической схемы (логический дизайн, независимый от физического хранения).
целостность данных и безопасность данных — обеспечение корректности и централизованный контроль доступа.
процессор запросов выполняет запросы; интерфейс разработчика предоставляет инструменты и API для создания приложений.
Его инструменты включают редактор словаря данных, конструктор запросов, конструктор форм, генератор отчетов, управление пользователями и редактор SQL.
Что содержит словарь данных (вопрос типа «назовите три элемента»): имена таблиц; имена полей в каждой таблице; тип данных и длину каждого поля; первичные и внешние ключи, а также связи между таблицами; правила валидации; индексы; и кто может получить доступ к каждой таблице. Это метаданные — данные о данных — и СУБД использует их для проверки каждого запроса и каждого изменения.
Как СУБД обеспечивает безопасность данных (вопрос типа «опишите два метода»): аутентификация — имя пользователя и пароль или биометрия перед любым доступом; права доступа — каждому пользователю или группе разрешено читать, записывать или удалять только определенные таблицы или поля, часто через представление; шифрование хранимых данных и данных, передаваемых им, чтобы скопированный файл был недоступен; резервные копии, создаваемые регулярно, чтобы данные можно было восстановить после потери; и журнал транзакций, фиксирующий, кто и что изменил.
Два программных инструмента.Интерфейс разработчика — это то, что использует программист для создания базы данных и приложений на ней: создания таблиц и установки ключей и правил валидации, написания запросов и SQL, а также дизайна форм и отчетов, не зная, как физически хранятся данные. Процессор запросов принимает запрос (SQL из программы или запрос, созданный в интерфейсе), проверяет его на соответствие словарю данных, определяет наиболее эффективный способ его выполнения, извлекает данные и возвращает результаты.
Логическая схема. СУБД сохраняет логический дизайн (какие таблицы и поля существуют и как они связаны) отдельно от физического хранения (файлы, индексы, блоки диска). Программы работают с логической схемой, поэтому физическое хранение может быть реорганизовано без изменения единой программы — это независимость данных, которой lacked файловый подход.
Show understanding that the DBMS carries out all creation/modification of the database structure using its Data Definition Language (DDL)
Show understanding that the DBMS carries out all queries and maintenance of data using its DML
Show understanding that the industry standard for both DDL and DML is Structured Query Language (SQL)
Understand a given SQL statement
Understand given SQL (DDL) statements and be able to write simple SQL (DDL) statements using a sub-set of statements
Create a database (CREATE DATABASE) Create a table definition (CREATE TABLE), including the creation of attributes with appropriate data types: • CHARACTER • VARCHAR(n) • BOOLEAN • INTEGER • REAL • DATE • TIME change a table definition (ALTER TABLE) add a primary key to a table (PRIMARY KEY (field)) add a foreign key to a table (FOREIGN KEY (field) REFERENCES Table (Field))
Write an SQL script to query or modify data (DML) which are stored in (at most two) database tables
Queries including SELECT... FROM, WHERE, ORDER BY, GROUP BY, INNER JOIN, SUM, COUNT, AVG
Data maintenance including INSERT INTO, DELETE FROM, UPDATE
Русский
Кандидаты должны уметь:
Примечания и рекомендации
Проявить понимание того, что СУБД выполняет все операции создания/изменения структуры базы данных с помощью своего Языка определения данных (DDL)
Проявить понимание того, что СУБД выполняет все запросы и обслуживание данных с помощью своего Языка манипулирования данными (DML)
Проявить понимание того, что отраслевым стандартом как для DDL, так и для DML является Structured Query Language (SQL)
Понимать заданное SQL-выражение
Понимать заданные SQL-выражения (DDL) и уметь писать простые SQL-выражения (DDL) с использованием подмножества команд
Создание базы данных (CREATE DATABASE) Создание определения таблицы (CREATE TABLE), включая создание атрибутов с подходящими типами данных: • CHARACTER • VARCHAR(n) • BOOLEAN • INTEGER • REAL • DATE • TIME Изменение определения таблицы (ALTER TABLE) Добавление первичного ключа к таблице (PRIMARY KEY (field)) Добавление внешнего ключа к таблице (FOREIGN KEY (field) REFERENCES Table (Field))
Написать SQL-скрипт для запроса или изменения данных (DML), хранящихся в (не более чем двух) таблицах базы данных
Запросы включают: SELECT... FROM, WHERE, ORDER BY, GROUP BY, INNER JOIN, SUM, COUNT, AVG
Обслуживание данных, включая INSERT INTO, DELETE FROM, UPDATE
Source: Cambridge International syllabus · Источник: Программа Cambridge International
English
SQL 结构化查询语言 (Structured Query Language) has two halves:
Data Definition Language 数据定义语言 (DDL) — creates or changes the structure (tables, keys, constraints).
Data Manipulation Language 数据操纵语言 (DML) — works with the data (insert, update, delete, query 查询).
DDL basics
Add a foreign key:
Modify and drop:
Common types: INTEGER, REAL, VARCHAR(n), CHAR(n) (also CHARACTER(n)), DATE, TIME, BOOLEAN, DECIMAL(p, s).
DML basics
Query with SELECT:
SELECT lists fields, FROM names the table, WHERE filters rows, ORDER BY sorts.
A join 连接 combines two tables using a foreign-key relationship:
Aggregate functions 聚合函数 (COUNT, SUM, AVG, MIN, MAX) are often used with GROUP BY:
Insert, update, delete:
Always put a WHERE clause on UPDATE and DELETE, or the change hits every row.
Tips for exam SQL
use the exact table and field names from the question.
quote strings with single quotes ('Smith'); don't quote numbers.
comparisons: =, <, >, <=, >=, <>.
LIKE 'A%' matches anything starting with A (% = any string, _ = one character); IN (1,2,3); BETWEEN 10 AND 20.
combine conditions with AND / OR / NOT, and end each statement with a semicolon.
The DDL pattern the exam wants. Every CREATE TABLE names each field with its type, marks the primary key, and declares each foreign key with the table it references; a composite key is declared on its own line:
Worked example. Using CUSTOMER(CustomerID, Name, Phone) and DEVICE(DeviceID, CustomerID, Type, Model), write SQL scripts to: (a) list the name and phone number of every customer who owns a device of type 'tablet', in alphabetical order of name; (b) count the devices of each type; (c) record that customer 17 now has the phone number '0771 234 5678'; (d) add a new device, ID 305, a 'laptop' of model 'X1' belonging to customer 17.
(a)
(b)
(c) UPDATE CUSTOMER SET Phone = '0771 234 5678' WHERE CustomerID = 17;
(d) INSERT INTO DEVICE (DeviceID, CustomerID, Type, Model) VALUES (305, 17, 'laptop', 'X1');
Marks are given per clause — the fields, the tables, the join condition, the WHERE, the ORDER BY — so a script with one wrong clause still scores the rest. Write Table.Field whenever two tables are involved.
Worked example. Explain what this script does: SELECT T.Name, SUM(R.Cost) AS Total FROM TECHNICIAN T INNER JOIN REPAIR R ON T.TechnicianID = R.TechnicianID GROUP BY T.Name;
It outputs each technician's name with the total cost of the repairs that technician has carried out, one row per technician: the two tables are joined on TechnicianID, the rows are grouped by name, and the costs in each group are added. When asked what a script does, describe the result, not the syntax.
Русский
SQL (Structured Query Language) имеет две половины:
DDL создает структуру базы данных; DML работает с данными
Язык определения данных (DDL) — создает или изменяет структуру (таблицы, ключи, ограничения).
Язык манипулирования данными (DML) — работает с данными (вставка, обновление, удаление, запрос).
Основы DDL
CREATE TABLE CUSTOMER (
CustomerID INTEGER PRIMARY KEY,
Name VARCHAR(50) NOT NULL,
Phone VARCHAR(20)
);
ALTER TABLE CUSTOMER ADD Email VARCHAR(100);
DROP TABLE CUSTOMER;
Распространенные типы: INTEGER, REAL, VARCHAR(n), CHAR(n) (также CHARACTER(n)), DATE, TIME, BOOLEAN, DECIMAL(p, s).
Основы DML
Запрос с помощью SELECT:
Запрос SELECT возвращает только строки, соответствующие условию
SELECT Name, Phone
FROM CUSTOMER
WHERE City = 'London'
ORDER BY Name ASC;
SELECT перечисляет поля, FROM называет таблицу, WHERE фильтрует строки, ORDER BY сортирует.
JOIN объединяет две таблицы с использованием связи внешнего ключа:
SELECT C.Name, O.OrderDate
FROM CUSTOMER C INNER JOIN ORDER O
ON C.CustomerID = O.CustomerID
WHERE O.OrderDate >= '2024-01-01';
Части запроса в порядке их написания
Агрегатные функции (COUNT, SUM, AVG, MIN, MAX) часто используются вместе с GROUP BY:
SELECT CustomerID, COUNT(*) AS NumOrders
FROM ORDER
GROUP BY CustomerID;
Вставить, обновить, удалить:
INSERT INTO CUSTOMER (CustomerID, Name, Phone)
VALUES (101, 'Ada Lovelace', '020-1234-5678');
UPDATE CUSTOMER SET Phone = '020-9999-0000' WHERE CustomerID = 101;
DELETE FROM CUSTOMER WHERE CustomerID = 101;
Всегда добавляйте clause WHERE к UPDATE и DELETE, иначе изменение затронет каждую строку.
Советы по SQL на экзамене
используйте точные имена таблиц и полей из вопроса.
обводите строки одинарными кавычками ('Smith'); не обводите числа.
сравнения: =, <, >, <=, >=, <>.
LIKE 'A%' совпадает с любым значением, начинающимся с A (% = любая строка, _ = один символ); IN (1,2,3); BETWEEN 10 AND 20.
объединяйте условия с помощью AND / OR / NOT и завершайте каждое выражение точкой с запятой.
Шаблон DDL, который требуется на экзамене. Каждый CREATE TABLE определяет имя каждого поля с его типом, указывает первичный ключ и объявляет каждый внешний ключ вместе с таблицей, на которую он ссылается; составной ключ объявляется в отдельной строке:
Разобранное решение. Используя CUSTOMER(CustomerID, Name, Phone) и DEVICE(DeviceID, CustomerID, Type, Model), напишите SQL-скрипты для: (a) вывода имени и номера телефона каждого клиента, владеющего устройством типа 'tablet', в алфавитном порядке по имени; (b) подсчета количества устройств каждого типа; (c) записи того, что у клиента 17 теперь номер телефона '0771 234 5678'; (d) добавления нового устройства ID 305, устройства 'laptop' модели 'X1', принадлежащего клиенту 17.
(a)
SELECT CUSTOMER.Name, CUSTOMER.Phone
FROM CUSTOMER INNER JOIN DEVICE
ON CUSTOMER.CustomerID = DEVICE.CustomerID
WHERE DEVICE.Type = 'tablet'
ORDER BY CUSTOMER.Name ASC;
(b)
SELECT Type, COUNT(DeviceID) AS NumberOfDevices
FROM DEVICE
GROUP BY Type;
(c) UPDATE CUSTOMER SET Phone = '0771 234 5678' WHERE CustomerID = 17;
(d) INSERT INTO DEVICE (DeviceID, CustomerID, Type, Model) VALUES (305, 17, 'laptop', 'X1');
Баллы начисляются за каждую часть запроса — поля, таблицы, условие соединения, WHERE, ORDER BY — поэтому скрипт с одной ошибочной частью все равно получит баллы за остальные. Пишите Table.Field, когда участвуют две таблицы.
Разобранное решение. Объясните, что делает этот скрипт: SELECT T.Name, SUM(R.Cost) AS Total FROM TECHNICIAN T INNER JOIN REPAIR R ON T.TechnicianID = R.TechnicianID GROUP BY T.Name;
Он выводит имя каждого техника с общей стоимостью ремонтов, которые он выполнил, по одной строке на техника: две таблицы соединены по TechnicianID, строки сгруппированы по имени, а затраты в каждой группе суммируются. Когда спрашивают, что делает скрипт, опишите результат, а не синтаксис.
Explore · Исследовать
Stitch two tables with INNER JOIN · Объединение двух таблиц с помощью INNER JOIN
A join matches rows where the foreign key equals the primary key — here Orders.CustomerID = Customer.CustomerID — and combines each matching pair into one wider row. · JOIN сопоставляет строки, где внешний ключ равен первичному ключу — здесь Orders.CustomerID = Customer.CustomerID — и объединяет каждую пару совпадений в одну более широкую строку.
Explore · Исследовать
SELECT … WHERE
Step through a query: WHERE keeps the rows that match, then SELECT picks the columns you asked for. · Пройдите пошагово запрос: WHERE оставляет только строки, соответствующие условию, затем SELECT выбирает запрошенные столбцы.
Define the terms exactly: entity, attribute, primary key, foreign key, and the relationship types (1:1, 1:many, many:many).
Give a reason at each normal form: 1NF (no repeating groups), 2NF (no partial dependency), 3NF (no non-key dependency) — and name the fields involved.
Explain what a DBMS provides (data independence, security, integrity, concurrent access, a data dictionary, a developer interface, a query processor).
Distinguish DDL (define the structure) from DML (query and change the data), and write SQL clause by clause: SELECT, FROM, INNER JOIN … ON, WHERE, GROUP BY, ORDER BY.
To draw an E-R diagram from tables, find each foreign key first: every foreign key is one one-to-many relationship, with the "many" at the table that holds it.
Common mistakes
Drawing a many-to-many relationship directly. It must be split into two one-to-many relationships through a link table holding both foreign keys.
Explaining "not in 3NF" by "the data is repeated". Name the dependency (partial or transitive) and the fields involved.
Double quotes round strings in SQL, or quotes round numbers. Strings take 'single quotes'; numbers take none.
Leaving out the ON condition after INNER JOIN. Without it the two tables are not linked.
Putting an ordinary field next to COUNT or SUM in a SELECT without a GROUP BY.
UPDATE or DELETE without a WHERE. It changes or removes every row in the table.
Русский
Определите термины точно: сущность, атрибут, первичный ключ, внешний ключ и типы отношений (1:1, 1:многие, многие:многие).
Дайте причину для каждой нормальной формы: 1NF (нет повторяющихся групп), 2NF (нет частичной зависимости), 3NF (нет зависимости непервичного атрибута) — и назовите涉及的的 поля.
Объясните, что предоставляет DBMS (независимость данных, безопасность, целостность, совместный доступ, словарь данных, интерфейс разработчика, процессор запросов).
Различайте DDL (определение структуры) и DML (запросы и изменение данных), и пишите SQL-запрос по частям: SELECT, FROM, INNER JOIN … ON, WHERE, GROUP BY, ORDER BY.
Чтобы нарисовать E-R диаграмму по таблицам, сначала найдите каждый внешний ключ: каждый внешний ключ — это одно отношение «один ко многим», где «многие» находятся в таблице, содержащей этот ключ.
Распространенные ошибки
Отрисовка отношения «многие ко многим» напрямую. Его необходимо разбить на два отношения «один ко многим» через промежуточную таблицу, содержащую оба внешних ключа.
Объяснение «не в 3NF» через «данные дублируются». Назовите зависимость (частичную или транзитивную) и涉及的的 поля.
Кавычки окружают строки в SQL, или кавычки окружают числа. Строки требуют 'single quotes'; числа требуют ничего.
Пропуск условия ON после INNER JOIN. Без него две таблицы не будут связаны.
Размещение обычного поля рядом с COUNT или SUM в структуре SELECT без наличия GROUP BY.
UPDATE или DELETE без наличия WHERE. Она изменяет или удаляет все строки в таблице.
Interactive lessons on this topic · Интерактивные уроки по этой теме
Work through it step by step, with instant-check exercises. · Пройдите его шаг за шагом с упражнениями мгновенной проверки.
Pick one and the site follows you — notes, papers, videos and practice all open on it. · Выберите один, и сайт будет вести вас — конспекты, работы, видео и практика откроются там.
Type to search notes, lessons, code, vocabulary and past-paper questions across every subject. · Введите запрос для поиска заметок, уроков, кода, словаря и вопросов с реальных экзаменов по всем предметам.
