Right off the bat, I think your example will make a lot more sense if you invert your structure so that an album is a child property of a Band (which is composed of a group of artists). With document-based NoSQL solutions, I find it helpful to sketch out the classes up front, and sometimes use nested classes (in C#) so that the top-level classes represent the Document Collection types. How you nest your classes, or which classes are top-level documents kind of depends on how you are going to interact with this data. A very common approach would be for one document to reference another by its ID, and a few denormalized fields that are commonly called. Take a look at this 2min class structure I whipped up in C# for your Music Store example in the question:
    

    // top-level document
    public class Band
    {
        public BandMate[] BandMembers { get; set; }

        public class BandMate
        {
            public DateTime Joined { get; set; }
            public DateTime? Left { get; set; } // nullable
            public string ArtistName { get; set; }
            public string ArtistId { get; set; }
        }

        public class Album
        {
            public string Title { get; set; }
            public DateTime ReleaseDate { get; set; }
            public Song[] Songs { get; set; }

            public class Song
            {
                public string Title { get; set; }
                public string Lyrics { get; set; }
            }
        }
    }


    // top-level document
    public class Artist
    {
        public string Name { get; set; }
        public string Id { get; set; }
        public DateTime DateOfBirth { get; set; }
        public string[] Background { get; set; }
        public Instrument[] InstrumentsKnown { get; set; }
        // more fields here for divorces, children, overdoses, etc....
    }

Some objects, like Songs, are contained completely within the parent class, so they are entirely part of the larger "Band" document/class. However, the Artists themselves might contain lots of lots of information that isn't 100% necessary when rendering Album information, which probably just cares about their names, or maybe their instruments. So the BandMate class contains the Artist ID, in case you want to do lookups on the Artist document for that full info, but also includes their denormalized Name, so that it is very easy to render the membership of the band from a simple query on Album. This level of denormalization is up to you, and constrained by the flavor of Document NoSQL database you choose.

Finally, without trying to sound condescending, if you aren't familiar with a paradigm like DocumentDb/NoSQL, then its pretty easy to say "Oh well I guess MY apps data is purely relational," when really its just that you've been using relational DB's to store 99% of application data for years since that's whats most commonly available (prior to this wonderful new era of MongoDb/CouchDb/RavenDb/etc). This example doesn't really show the full power of schema-less storage, but in C# for example, I can store child object collections under the label of an interface, and the NoSQL db can do the work of initializing them to their original type, without me having to care about setting up diff tables and JOINing all that stuff together.