As @amdluigi says, "Usually, the name of assembly is the same as a namespace that it contains but not always".
There is a screenshot above of System.Data.dll in the Object Browser in Studio. It's an excellent example to explore the issues here. Note that most of the namespaces contained within the assembly are System.Data or a sub-namespace of System.Data.
In general, it is a good practice for assembly names to be related to the namespaces within them. Notice that when Studio first creates a project to build an assembly, one of the project properties is a default namespace. At the start, Studio gives default namespace the same name as the project itself. If you ever choose to rename a project, do consider changing its default namespace as well.
There are two extra namespaces: Microsoft.SqlServer is understandable. Some SQL Server types that they didn't want to package in a separate assembly.
But what's with System.Xml???? There is a System.Xml.dll assembly. Why is this namespace showing up in System.Data.dll as well?
Notice that an assembly can reopen a namespace and add more to it - that's exactly what System.Data.dll is doing with the System.Xml namespace.
The reason is that namespaces have zero performance implications, but assemblies very much do. If you have 1000 classes with substantial amounts of code, you don't want one assembly with a very large memory footprint. Neither do you want 1000 assemblies each with one class. Any assembly needs to be loaded into memory before its contents can be executed. You want an assembly to contain a reasonable number of interrelated classes, so once your application has loaded an assembly to obtain one of its classes, it gets other classes the application is likely to need for free. Granularity is important: not too big, not too small, just right.
Notice that System.Data.dll reopens System.Xml and adds exactly one class: XmlDataDocument. It happens that this class is used to interpret relational data as an XML document. If your application is just using XML, it won't need this class. If your application deals with relational data, it might. So while XmlDataDocument inherits from XmlDocument and is in the System.Xml namespace, it's packaged in the System.Data.dll assembly.
All this is particularly important if you have a background with Java, where there is only one concept, the package. In .NET there are two, the assembly and the namespace. The two are orthogonal. An assembly can obviously contain more than one namespace. An assembly can reopen a namespace and add more to it - in other words, the types in a namespace may span more than one assembly.